... with less code, sorry forgot to mention ;-)
Werner
On Wed, Aug 26, 2015 at 12:10 PM, Werner Keil <werner.keil(a)gmail.com> wrote:
Hi,
public class JmsRegistrar {
@Inject
@JmsConnectionFactory(...)
private ConnectionFactory factory;
@Inject
@JmsQueue(...)
private Queue queue;
public void startJms(@Observes JmsStart start) {
start.withFactory(factory) // withFactory should be optional if
only 1 bean matches it
.register(BookingListener.class) // with defaults for all
potential config
.listenOn(queue)
.register(BookingListener2.class, new BookingLiteral2())
.withMaxSessions(10)
.listenOn(Queue.class, new QueueLiteral(...))
......;
}
}
it could allow to accomplish what I did (loosely based on
http://www.jboss.org/quickstarts/eap/payment-cdi-event/) forwarding MDB
events to custom CDI ones like that.
Class BookingMDB:
@Inject
private BookingBean booker;
public void onMessage(Message rcvMessage) {
BytesMessage msg = null;
try {
if (rcvMessage instanceof BytesMessage) {
msg = (BytesMessage) rcvMessage;
byte[] output = new byte[5];
msg.readBytes(output);
booker.book(output);
} else {
LOGGER.warning("Message of wrong type: " +
rcvMessage.getClass().getName());
}
} catch (JMSException e) {
throw new RuntimeException(e);
}
}
Class BookingBean:
public void book(byte[] msg) {
BookingEvent bookingEvent = new BookingEvent();
if (msg[256] = 42}
bookingEvent.setType(BookingType.OK);
} else {
<some other message data triggering a different booking event>
}
bookingEvent.setMessage(msg);
bookingEvent.setDatetime(LocalDateTime.now());
switch (bookingEvent.getType()) {
case OK:
BookingEventProducer.fire(bookingEvent);
break;
case [...]
default:
LOGGER.severe("invalid booking option");
break;
}
}
You'll get the idea about other types involved from the standard CDI
example.
We're dealing with BytesMessage because part of that booking process
happens on host servers;-)
Werner
On Wed, Aug 26, 2015 at 11:16 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Romain Manni-Bucau)
> 4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Nigel Deakin)
> 5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Romain Manni-Bucau)
> 7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Romain Manni-Bucau)
>
> ------------------------------
>
> Message: 7
> Date: Wed, 26 Aug 2015 11:16:04 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=
> 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin(a)oracle.com>:
>
> > (Tidying up the top-posting...)
> >
> > Romain Manni-Bucau:
> > > ...I see it really nice to not rely only on annotation - and aligned
> with
> > > most specs - since sometimes you just want to either be able to rely
> on a
> > > loop or a custom config to register your listeners. Annotations are
> too
> > > rigid for such cases.
> >
> > Nigel:
> > > Obviously, if users don't want to use CDI (or MDBs, which are also
> > > declarative), then they would use the normal JMS API. The existing
> > > API to register an async message listener isn't good enough,
> > > and we may improve it in JMS 2.1, but that's not something that
> > > I'd want to bother the people on cdi-dev with.
> >
> > Romain Manni-Bucau:
> > > Integrating it in CDI lifecycle through an event allow CDI users to
> still
> > > use it in the right phase of the container boot so it is still
> important
> > > IMO and avoid all users to have their own custom listener for it -
> > > @Initialized(AppScoped.class). Also allow to enrich the API through
> the
> > event
> > > itself making things smoother IMO.
> >
> > Nigel:
> > > I'm sorry I don't understand you.
> > > I thought you were asking about an API which does not use annotation.
> >
> > Romain Manni-Bucau:
> > > Both are needed (like websocket spec). Annotation one is nice for
> fully
> > business
> > > code and/or simple libs but relying on CDI allows to simplify the
> wiring
> > since you
> > > can reuse CDI beans under the hood ie have an implicit connection
> > factory if
> > > there is a single one etc which is not possible in fully SE context.
> >
> > Can you explain the distinction you're making here? You seem to be
> > suggesting two alternatives, using "annotation" and "relying on
CDI".
> What
> > would an application which uses CDI but which doesn't use annotation
> look
> > like?
> >
> >
> The sample I gave before with the JmsStart event basically:
>
>
> public class JmsRegistrar {
> @Inject
> @JmsConnectionFactory(...)
> private ConnectionFactory factory;
>
> @Inject
> @JmsQueue(...)
> private Queue queue;
>
> public void startJms(@Observes JmsStart start) {
> start.withFactory(factory) // withFactory should be optional if
> only 1 bean matches it
> .register(MyCdiTypedListener.class) // with defaults for
> all
> potential config
> .listenOn(queue)
> .register(MyCdiTypedListener2.class, new MyLiteral())
> .withMaxSessions(10)
> .listenOn(Queue.class, new QueueLiteral(...))
> ......;
> }
> }
>
>
> The power of it appears when you have a config injection in JmsRegistrar
> you can iterate over to get the list of listener for instance.
>
> Also JMS resources can be decorated and referenced from qualifiers instead
> of instances thanks to CDI.
>
> It doesnt prevent the app to use @JmxListener somewhere else if the
> listener doesnt need any input/config to be registered.
>
>
> > Nigel
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
>
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 57, Issue 21
> ***************************************
>