[cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
Werner Keil
werner.keil at gmail.com
Wed Aug 26 06:10:37 EDT 2015
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 at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at 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: 1
> Date: Tue, 25 Aug 2015 22:53:21 +0200
> From: arjan tijms <arjan.tijms at 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 at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAE=-AhCnTyS-ZVAfT9k2jDK=
> k6QHW4ShUab_Vt+e6WmBN76gWg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
> > On 25/08/2015 12:38, arjan tijms wrote:
> > This looks very interesting. Does this work with any normal scope?
>
> Yes, all normal scopes that are available in standard Java EE support
> this as far as I know.
>
> There's the small caveat that CDI itself doesn't know about this
> automatically for any custom normal scope. That implementation of such
> scope (via a Context) must explicitly throw these events.
>
> For example, this is what Mojarra does for the @FlowScoped implementation:
>
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
>
> Which is fired when the scope starts here:
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
>
> (the exact same code is used for @ViewScoped in Mojarra as well)
>
>
> > then every time a new request starts, this event is fired which causes an
> > instance of the bean to be created for that request?
>
> Yes, that is what this does ;)
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 25 Aug 2015 23:16:27 +0200
> From: arjan tijms <arjan.tijms at 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 at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAE=-
> AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
> > Someone over on the JMS user alias told me about this yesterday. So that
> > would avoid the need to call a method to trigger lazy initialisation on
> > normal-scoped bean proxies. I presume the application still has to inject
> > the bean.
>
> The bean does not necessarily have to be injected at any point.
>
> With @Eager it will be activated and its @PostConstruct method will be
> invoked in case it hadn't been referenced before (which in case of
> @Eager is unlikely, as it instantiates very early, but still
> theoretically possible).
>
> The bean can of course still be injected or otherwise referenced later
> within the same scope, but as mentioned this is not required.
>
> So for example if you have OmniFaces on your classpath and then only
> the following bean in an application:
>
> @Eager
> @ApplicationScoped
> public class MyEagerApplicationScopedBean {
>
> @PostConstruct
> public void init() {
> System.out.println("Application scoped init!");
> }
> }
>
> Then you'll see "Application scoped init!" being printed in your
> server log when you deploy that application. No other code is needed.
>
>
> > If so then it sounds useful. Is it going to be included as a standard
> > feature of CDI 2.0? I see someone has proposed
> > https://issues.jboss.org/browse/CDI-473 .
>
> As the issue already mentions, this is possible with current day CDI
> already. The proposal may arguably make it a little more concise and a
> little less verbose. An eager attribute on the scope looks like a
> quite minimal and elegant solution. Additionally it may make sense for
> some scopes to restrict for which "IDs' it's eagerly instantiated
> (e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for
> @FlowScoped, etc).
>
> A new @Startup seems more like a very specific usage of the eager
> attribute, namely for @ApplicationScoped (or Singleton?) beans.
>
> Kind regards,
> Arjan
>
>
>
>
>
> >
> > Nigel
> >
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 10:11:21 +0200
> From: Romain Manni-Bucau <rmannibucau at 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: arjan tijms <arjan.tijms at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=
> SyQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
>
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin at oracle.com>
> > wrote:
> > > On 25/08/2015 12:38, arjan tijms wrote:
> > > This looks very interesting. Does this work with any normal scope?
> >
> > Yes, all normal scopes that are available in standard Java EE support
> > this as far as I know.
> >
> >
> Events are not mandatory for a normal scope - at least was the case in 1.2
> - so JMS can't rely on it for custom normal scopes.
>
>
> > There's the small caveat that CDI itself doesn't know about this
> > automatically for any custom normal scope. That implementation of such
> > scope (via a Context) must explicitly throw these events.
> >
> > For example, this is what Mojarra does for the @FlowScoped
> implementation:
> >
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
> >
> > Which is fired when the scope starts here:
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
> >
> > (the exact same code is used for @ViewScoped in Mojarra as well)
> >
> >
> > > then every time a new request starts, this event is fired which causes
> an
> > > instance of the bean to be created for that request?
> >
> > Yes, that is what this does ;)
> >
> > Kind regards,
> > Arjan Tijms
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at 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.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c1f05f1c/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 10:07:01 +0100
> From: Nigel Deakin <nigel.deakin at oracle.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: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DD81B5.9040407 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> (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?
>
> Nigel
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 26 Aug 2015 11:07:46 +0200
> From: arjan tijms <arjan.tijms at 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: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAE=-
> AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> <rmannibucau at gmail.com> wrote:
> >> Yes, all normal scopes that are available in standard Java EE support
> >> this as far as I know.
> >>
> >
> > Events are not mandatory for a normal scope - at least was the case in
> 1.2 -
> > so JMS can't rely on it for custom normal scopes.
>
> Absolutely true, but that was exactly what I said ;)
>
> All Java EE provided scopes throw the events. For CDI, this is
> mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> @ApplicationScoped and @ConversationScoped.
>
> For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> have to double check whether this is actually in the spec for those
> last two and if not see if we can update it for 2.3.
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 26 Aug 2015 11:09:30 +0200
> From: Romain Manni-Bucau <rmannibucau at 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: arjan tijms <arjan.tijms at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=
> kL6gyb5jHb7fdA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
>
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > <rmannibucau at gmail.com> wrote:
> > >> Yes, all normal scopes that are available in standard Java EE support
> > >> this as far as I know.
> > >>
> > >
> > > Events are not mandatory for a normal scope - at least was the case in
> > 1.2 -
> > > so JMS can't rely on it for custom normal scopes.
> >
> > Absolutely true, but that was exactly what I said ;)
> >
> > All Java EE provided scopes throw the events. For CDI, this is
> > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> > @ApplicationScoped and @ConversationScoped.
> >
> > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> > have to double check whether this is actually in the spec for those
> > last two and if not see if we can update it for 2.3.
> >
> >
> Agree for provided scope but JMS + short time scopes will not match well in
> practise so i would worry more about not "default" scopes which can miss
> these events.
>
>
> > Kind regards,
> > Arjan Tijms
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment-0001.html
>
> ------------------------------
>
> Message: 7
> Date: Wed, 26 Aug 2015 11:16:04 +0200
> From: Romain Manni-Bucau <rmannibucau at 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 at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CACLE=
> 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin at 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/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c56ea2e7/attachment-0001.html
More information about the cdi-dev
mailing list