[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:21:38 EDT 2015
Good point. What I tried to sketch out from my example here was mapping a
"JMS container listener" (MDB) to a "business" or "user" listener making
sense for the business logic of a particular application domain.
Werner
On Wed, Aug 26, 2015 at 12:10 PM, <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 (Nigel Deakin)
> 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Romain Manni-Bucau)
> 3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Werner Keil)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 26 Aug 2015 10:43:40 +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: Jozef Hartinger <jharting at redhat.com>, Romain Manni-Bucau
> <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DD8A4C.7050107 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> >>
> >> For this last case a really elegant solution would be to just reuse
> >> @Observes to fire the message from the jms "container" listener and
> >> propagate it to the "user" listener. This would then allow to decouple
> >> the application listener from JMS.
>
> On 25/08/2015 15:26, Jozef Hartinger wrote:
> > Agreed. I think we should leverage the existing CDI event/observer
> functionality instead of introducing a completely new
> > delivery mechanism.
>
> Can you please say a bit more about what you have in mind?
>
> Romain suggests using events to invoke the "user" listener from the "JMS
> container listener".
> That's a useful distinction. Just to clarify the terminology:
>
> "user" listener = listener bean provided by the application
> "JMS container listener" = JMS consumer provided by the application server
> or resource adapter
>
> There needs to be one consumer for every listener bean since the two need
> to have the same lifecycle, and also so we can
> implement JMS queue sematics which require that a message from a queue is
> delivered to one and only one listener.
>
> The transaction needs to be started by the consumer before invoking the
> listener and ended after the listener returns.
> This allows the acknowledgement of the message (which is performed by the
> consumer) to take place in the same
> transaction as is used by the listener's method.
>
> Currently I'm proposing that the "consumer" invokes the "listener" by a
> simple method call. I suppose instead of simply
> invoking the method it could fire a synchronous event, which only the
> associated listener instance would receive, but
> I'm not sure what the benefit of this would be. Since JMS semantics are
> very different from CDI event semantics I think
> there's a danger that this will be confusing, since the user might think
> they were getting CDI event semantics, but they
> were actually getting JMS semantics.
>
> Since this is a bit of a FAQ, it might be useful to explore the
> differences between the two semantics, but currently
> they seem profoundly different to me. That's why my proposals are built on
> the CDI bean lifecycle model but not the CDI
> event observer model.
>
> Nigel
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 26 Aug 2015 11:46:57 +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=7MYErwNimYDz=
> 5C5+xD5MFV-T8M6wjyw9Ax8p59T6Z2ww at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Something I didnt think before but if you can register a method reference
> then CDI event system starts to be useless:
>
> xxx.register(myCdiBean::listenOn);
>
> can be something to investigate API wise maybe
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-08-26 11:43 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
>
> > > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> > >>
> > >> For this last case a really elegant solution would be to just reuse
> > >> @Observes to fire the message from the jms "container" listener and
> > >> propagate it to the "user" listener. This would then allow to decouple
> > >> the application listener from JMS.
> >
> > On 25/08/2015 15:26, Jozef Hartinger wrote:
> >
> >> Agreed. I think we should leverage the existing CDI event/observer
> >> functionality instead of introducing a completely new
> >> delivery mechanism.
> >>
> >
> > Can you please say a bit more about what you have in mind?
> >
> > Romain suggests using events to invoke the "user" listener from the "JMS
> > container listener".
> > That's a useful distinction. Just to clarify the terminology:
> >
> > "user" listener = listener bean provided by the application
> > "JMS container listener" = JMS consumer provided by the application
> server
> > or resource adapter
> >
> > There needs to be one consumer for every listener bean since the two need
> > to have the same lifecycle, and also so we can implement JMS queue
> sematics
> > which require that a message from a queue is delivered to one and only
> one
> > listener.
> >
> > The transaction needs to be started by the consumer before invoking the
> > listener and ended after the listener returns. This allows the
> > acknowledgement of the message (which is performed by the consumer) to
> take
> > place in the same transaction as is used by the listener's method.
> >
> > Currently I'm proposing that the "consumer" invokes the "listener" by a
> > simple method call. I suppose instead of simply invoking the method it
> > could fire a synchronous event, which only the associated listener
> instance
> > would receive, but I'm not sure what the benefit of this would be. Since
> > JMS semantics are very different from CDI event semantics I think
> there's a
> > danger that this will be confusing, since the user might think they were
> > getting CDI event semantics, but they were actually getting JMS
> semantics.
> >
> > Since this is a bit of a FAQ, it might be useful to explore the
> > differences between the two semantics, but currently they seem profoundly
> > different to me. That's why my proposals are built on the CDI bean
> > lifecycle model but not the CDI event observer model.
> >
> > Nigel
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a1a16971/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 11:51:30 +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=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=
> DAyVa3C54+2EtBK7-g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> <rmannibucau at gmail.com> wrote:
> > 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.
>
> Short lived scopes like @RequestScoped may not be the best match indeed.
>
> Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
> thing, e.g. there's the expectation that only the current thread will
> access it. If the JMS provider will asynchronously call a method on
> the bean instance from another thread, then this breaks this
> assumption.
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 12:10:37 +0200
> From: Werner Keil <werner.keil 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: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <
> CAAGawe1bxW1oA_s4t0RNPJCf2hQYgRMsPJatB-M8BCy7xuwRoA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.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 22
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/34139ad1/attachment-0001.html
More information about the cdi-dev
mailing list