<div dir="ltr">Hi,<div><br></div><div>public class JmsRegistrar {<br>    @Inject<br>    @JmsConnectionFactory(...)<br>    private ConnectionFactory factory;<br><br>    @Inject<br>    @JmsQueue(...)<br>    private Queue queue;<br><br>    public void startJms(@Observes JmsStart start) {<br>        start.withFactory(factory) // withFactory should be optional if<br>only 1 bean matches it<br>               .register(BookingListener.class) // with defaults for all<br>potential config<br>                   .listenOn(queue)<br>               .register(BookingListener2.class, new BookingLiteral2())<br>                    .withMaxSessions(10)<br>                    .listenOn(Queue.class, new QueueLiteral(...))<br>                    ......;<br>    }<br>}<br></div><div><br></div><div><br></div><div>it could allow to accomplish what I did (loosely based on <a href="http://www.jboss.org/quickstarts/eap/payment-cdi-event/">http://www.jboss.org/quickstarts/eap/payment-cdi-event/</a>) forwarding MDB events to custom CDI ones like that.</div><div><br></div><div><div>Class BookingMDB:</div><div>  </div><div>  @Inject</div><div>  private BookingBean booker;</div><div>  </div><div>   public void onMessage(Message rcvMessage) {</div><div>        BytesMessage msg = null;</div><div>        try {</div><div>            if (rcvMessage instanceof BytesMessage) {</div><div>                msg = (BytesMessage) rcvMessage;</div><div>                byte[] output = new byte[5];</div><div>                msg.readBytes(output);</div><div>                booker.book(output);</div><div>            } else {</div><div>                LOGGER.warning(&quot;Message of wrong type: &quot; + rcvMessage.getClass().getName());</div><div>            }</div><div>        } catch (JMSException e) {</div><div>            throw new RuntimeException(e);</div><div>        }</div><div><span class="" style="white-space:pre">        </span>}</div><div><span class="" style="white-space:pre">        </span></div><div>Class BookingBean:</div><div><span class="" style="white-space:pre">        </span></div><div>    public void book(byte[] msg) {</div><div>       BookingEvent bookingEvent = new BookingEvent();</div><div>       if (msg[256] = 42} </div><div>          bookingEvent.setType(BookingType.OK);</div><div>        } else { </div><div>           &lt;some other message data triggering a different booking event&gt;</div><div>        }</div><div>        bookingEvent.setMessage(msg);</div><div>        bookingEvent.setDatetime(LocalDateTime.now());</div><div><br></div><div>        switch (bookingEvent.getType()) {</div><div>            case OK:</div><div>                BookingEventProducer.fire(bookingEvent);</div><div>                break;</div><div><span class="" style="white-space:pre">            </span>case [...]</div><div>            default:</div><div>                LOGGER.severe(&quot;invalid booking option&quot;);</div><div>                break;</div><div>        }</div><div>    }</div></div><div><br></div><div>You&#39;ll get the idea about other types involved from the standard CDI example.<br><div class="gmail_extra">We&#39;re dealing with BytesMessage because part of that booking process happens on host servers;-)</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px;font-size:13px;border-collapse:collapse"><span lang="EN-US" style="font-family:Calibri">Werner</span></p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Aug 26, 2015 at 11:16 AM,  <span dir="ltr">&lt;<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send cdi-dev mailing list submissions to<br>
        <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
        <a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of cdi-dev digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
   1. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
      EE application to listen for JMS messages (arjan tijms)<br>
   2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
      EE application to listen for JMS messages (arjan tijms)<br>
   3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
      EE application to listen for JMS messages (Romain Manni-Bucau)<br>
   4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
      EE application to listen for JMS messages (Nigel Deakin)<br>
   5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
      EE application to listen for JMS messages (arjan tijms)<br>
   6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
      EE application to listen for JMS messages (Romain Manni-Bucau)<br>
   7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
      EE application to listen for JMS messages (Romain Manni-Bucau)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 25 Aug 2015 22:53:21 +0200<br>
From: arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;<br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
        in a Java EE application to listen for JMS messages<br>
To: Nigel Deakin &lt;<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>&gt;<br>
Cc: cdi-dev &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
Message-ID:<br>
        &lt;CAE=-AhCnTyS-ZVAfT9k2jDK=<a href="mailto:k6QHW4ShUab_Vt%2Be6WmBN76gWg@mail.gmail.com">k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi,<br>
<br>
On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin &lt;<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>&gt; wrote:<br>
&gt; On 25/08/2015 12:38, arjan tijms wrote:<br>
&gt; This looks very interesting. Does this work with any normal scope?<br>
<br>
Yes, all normal scopes that are available in standard Java EE support<br>
this as far as I know.<br>
<br>
There&#39;s the small caveat that CDI itself doesn&#39;t know about this<br>
automatically for any custom normal scope. That implementation of such<br>
scope (via a Context) must explicitly throw these events.<br>
<br>
For example, this is what Mojarra does for the @FlowScoped implementation:<br>
<br>
<a href="https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java" rel="noreferrer" target="_blank">https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java</a><br>
<br>
Which is fired when the scope starts here:<br>
<a href="https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431" rel="noreferrer" target="_blank">https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431</a><br>
<br>
(the exact same code is used for @ViewScoped in Mojarra as well)<br>
<br>
<br>
&gt; then every time a new request starts, this event is fired which causes an<br>
&gt; instance of the bean to be created for that request?<br>
<br>
Yes, that is what this does ;)<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 25 Aug 2015 23:16:27 +0200<br>
From: arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;<br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
        in a Java EE application to listen for JMS messages<br>
To: Nigel Deakin &lt;<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>&gt;<br>
Cc: cdi-dev &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
Message-ID:<br>
        &lt;CAE=-<a href="mailto:AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2%2BDQ@mail.gmail.com">AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi,<br>
<br>
On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin &lt;<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>&gt; wrote:<br>
&gt; Someone over on the JMS user alias told me about this yesterday. So that<br>
&gt; would avoid the need to call a method to trigger lazy initialisation on<br>
&gt; normal-scoped bean proxies. I presume the application still has to inject<br>
&gt; the bean.<br>
<br>
The bean does not necessarily have to be injected at any point.<br>
<br>
With @Eager it will be activated and its @PostConstruct method will be<br>
invoked in case it hadn&#39;t been referenced before (which in case of<br>
@Eager is unlikely, as it instantiates very early, but still<br>
theoretically possible).<br>
<br>
The bean can of course still be injected or otherwise referenced later<br>
within the same scope, but as mentioned this is not required.<br>
<br>
So for example if you have OmniFaces on your classpath and then only<br>
the following bean in an application:<br>
<br>
@Eager<br>
@ApplicationScoped<br>
public class MyEagerApplicationScopedBean {<br>
<br>
     @PostConstruct<br>
     public void init() {<br>
         System.out.println(&quot;Application scoped init!&quot;);<br>
     }<br>
 }<br>
<br>
Then you&#39;ll see &quot;Application scoped init!&quot; being printed in your<br>
server log when you deploy that application. No other code is needed.<br>
<br>
<br>
&gt; If so then it sounds useful. Is it going to be included as a standard<br>
&gt; feature of CDI 2.0? I see someone has proposed<br>
&gt; <a href="https://issues.jboss.org/browse/CDI-473" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-473</a> .<br>
<br>
As the issue already mentions, this is possible with current day CDI<br>
already. The proposal may arguably make it a little more concise and a<br>
little less verbose. An eager attribute on the scope looks like a<br>
quite minimal and elegant solution. Additionally it may make sense for<br>
some scopes to restrict for which &quot;IDs&#39; it&#39;s eagerly instantiated<br>
(e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for<br>
@FlowScoped, etc).<br>
<br>
A new @Startup seems more like a very specific usage of the eager<br>
attribute, namely for @ApplicationScoped (or Singleton?) beans.<br>
<br>
Kind regards,<br>
Arjan<br>
<br>
<br>
<br>
<br>
<br>
&gt;<br>
&gt; Nigel<br>
&gt;<br>
&gt;<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 26 Aug 2015 10:11:21 +0200<br>
From: Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt;<br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
        in a Java EE application to listen for JMS messages<br>
To: arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;<br>
Cc: cdi-dev &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
Message-ID:<br>
        &lt;CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=<a href="mailto:SyQ@mail.gmail.com">SyQ@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;utf-8&quot;<br>
<br>
2015-08-25 22:53 GMT+02:00 arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin &lt;<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>&gt;<br>
&gt; wrote:<br>
&gt; &gt; On 25/08/2015 12:38, arjan tijms wrote:<br>
&gt; &gt; This looks very interesting. Does this work with any normal scope?<br>
&gt;<br>
&gt; Yes, all normal scopes that are available in standard Java EE support<br>
&gt; this as far as I know.<br>
&gt;<br>
&gt;<br>
Events are not mandatory for a normal scope - at least was the case in 1.2<br>
- so JMS can&#39;t rely on it for custom normal scopes.<br>
<br>
<br>
&gt; There&#39;s the small caveat that CDI itself doesn&#39;t know about this<br>
&gt; automatically for any custom normal scope. That implementation of such<br>
&gt; scope (via a Context) must explicitly throw these events.<br>
&gt;<br>
&gt; For example, this is what Mojarra does for the @FlowScoped implementation:<br>
&gt;<br>
&gt;<br>
&gt; <a href="https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java" rel="noreferrer" target="_blank">https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java</a><br>
&gt;<br>
&gt; Which is fired when the scope starts here:<br>
&gt;<br>
&gt; <a href="https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431" rel="noreferrer" target="_blank">https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431</a><br>
&gt;<br>
&gt; (the exact same code is used for @ViewScoped in Mojarra as well)<br>
&gt;<br>
&gt;<br>
&gt; &gt; then every time a new request starts, this event is fired which causes an<br>
&gt; &gt; instance of the bean to be created for that request?<br>
&gt;<br>
&gt; Yes, that is what this does ;)<br>
&gt;<br>
&gt; Kind regards,<br>
&gt; Arjan Tijms<br>
&gt; _______________________________________________<br>
&gt; cdi-dev mailing list<br>
&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;<br>
&gt; Note that for all code provided on this list, the provider licenses the<br>
&gt; code under the Apache License, Version 2 (<br>
&gt; <a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
&gt; provided on this list, the provider waives all patent and other<br>
&gt; intellectual property rights inherent in such information.<br>
&gt;<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c1f05f1c/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c1f05f1c/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 26 Aug 2015 10:07:01 +0100<br>
From: Nigel Deakin &lt;<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>&gt;<br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
        in a Java EE application to listen for JMS messages<br>
To: Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt;<br>
Cc: cdi-dev &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
Message-ID: &lt;<a href="mailto:55DD81B5.9040407@oracle.com">55DD81B5.9040407@oracle.com</a>&gt;<br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
(Tidying up the top-posting...)<br>
<br>
Romain Manni-Bucau:<br>
 &gt; ...I see it really nice to not rely only on annotation - and aligned with<br>
 &gt; most specs - since sometimes you just want to either be able to rely on a<br>
 &gt; loop or a custom config to register your listeners. Annotations are too<br>
 &gt; rigid for such cases.<br>
<br>
Nigel:<br>
 &gt; Obviously, if users don&#39;t want to use CDI (or MDBs, which are also<br>
 &gt; declarative), then they would use the  normal JMS API. The existing<br>
 &gt; API to register an async message listener isn&#39;t good enough,<br>
 &gt; and we may improve it in JMS 2.1, but that&#39;s not something that<br>
 &gt; I&#39;d want to bother the people on cdi-dev with.<br>
<br>
Romain Manni-Bucau:<br>
 &gt; Integrating it in CDI lifecycle through an event allow CDI users to still<br>
 &gt; use it in the right phase of the container boot so it is still important<br>
 &gt; IMO and avoid all users to have their own custom listener for it -<br>
 &gt; @Initialized(AppScoped.class). Also allow to enrich the API through the event<br>
 &gt; itself making things smoother IMO.<br>
<br>
Nigel:<br>
 &gt; I&#39;m sorry I don&#39;t understand you.<br>
 &gt; I thought you were asking about an API which does not use annotation.<br>
<br>
Romain Manni-Bucau:<br>
 &gt; Both are needed (like websocket spec). Annotation one is nice for fully business<br>
 &gt; code and/or simple libs but relying on CDI allows to simplify the wiring since you<br>
 &gt; can reuse CDI beans under the hood ie have an implicit connection factory if<br>
 &gt; there is a single one etc which is not possible in fully SE context.<br>
<br>
Can you explain the distinction you&#39;re making here? You seem to be suggesting two alternatives, using &quot;annotation&quot; and<br>
&quot;relying on CDI&quot;. What would an application which uses CDI but which doesn&#39;t use annotation look like?<br>
<br>
Nigel<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 26 Aug 2015 11:07:46 +0200<br>
From: arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;<br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
        in a Java EE application to listen for JMS messages<br>
To: Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt;<br>
Cc: cdi-dev &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
Message-ID:<br>
        &lt;CAE=-<a href="mailto:AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com">AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi,<br>
<br>
On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau<br>
&lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt; wrote:<br>
&gt;&gt; Yes, all normal scopes that are available in standard Java EE support<br>
&gt;&gt; this as far as I know.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Events are not mandatory for a normal scope - at least was the case in 1.2 -<br>
&gt; so JMS can&#39;t rely on it for custom normal scopes.<br>
<br>
Absolutely true, but that was exactly what I said ;)<br>
<br>
All Java EE provided scopes throw the events. For CDI, this is<br>
mandated by the spec (6.7) for @RequestScoped, @SessionScoped,<br>
@ApplicationScoped and @ConversationScoped.<br>
<br>
For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I<br>
have to double check whether this is actually in the spec for those<br>
last two and if not see if we can update it for 2.3.<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 26 Aug 2015 11:09:30 +0200<br>
From: Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt;<br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
        in a Java EE application to listen for JMS messages<br>
To: arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;<br>
Cc: cdi-dev &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
Message-ID:<br>
        &lt;CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=<a href="mailto:kL6gyb5jHb7fdA@mail.gmail.com">kL6gyb5jHb7fdA@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;utf-8&quot;<br>
<br>
2015-08-26 11:07 GMT+02:00 arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt;:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau<br>
&gt; &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt; Yes, all normal scopes that are available in standard Java EE support<br>
&gt; &gt;&gt; this as far as I know.<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; Events are not mandatory for a normal scope - at least was the case in<br>
&gt; 1.2 -<br>
&gt; &gt; so JMS can&#39;t rely on it for custom normal scopes.<br>
&gt;<br>
&gt; Absolutely true, but that was exactly what I said ;)<br>
&gt;<br>
&gt; All Java EE provided scopes throw the events. For CDI, this is<br>
&gt; mandated by the spec (6.7) for @RequestScoped, @SessionScoped,<br>
&gt; @ApplicationScoped and @ConversationScoped.<br>
&gt;<br>
&gt; For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I<br>
&gt; have to double check whether this is actually in the spec for those<br>
&gt; last two and if not see if we can update it for 2.3.<br>
&gt;<br>
&gt;<br>
Agree for provided scope but JMS + short time scopes will not match well in<br>
practise so i would worry more about not &quot;default&quot; scopes which can miss<br>
these events.<br>
<br>
<br>
&gt; Kind regards,<br>
&gt; Arjan Tijms<br>
&gt;<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 26 Aug 2015 11:16:04 +0200<br>
From: Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>&gt;<br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
        in a Java EE application to listen for JMS messages<br>
To: Nigel Deakin &lt;<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>&gt;<br>
Cc: cdi-dev &lt;<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>&gt;<br>
Message-ID:<br>
        &lt;CACLE=<a href="mailto:7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com">7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;utf-8&quot;<br>
<br>
2015-08-26 11:07 GMT+02:00 Nigel Deakin &lt;<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>&gt;:<br>
<br>
&gt; (Tidying up the top-posting...)<br>
&gt;<br>
&gt; Romain Manni-Bucau:<br>
&gt; &gt; ...I see it really nice to not rely only on annotation - and aligned with<br>
&gt; &gt; most specs - since sometimes you just want to either be able to rely on a<br>
&gt; &gt; loop or a custom config to register your listeners. Annotations are too<br>
&gt; &gt; rigid for such cases.<br>
&gt;<br>
&gt; Nigel:<br>
&gt; &gt; Obviously, if users don&#39;t want to use CDI (or MDBs, which are also<br>
&gt; &gt; declarative), then they would use the  normal JMS API. The existing<br>
&gt; &gt; API to register an async message listener isn&#39;t good enough,<br>
&gt; &gt; and we may improve it in JMS 2.1, but that&#39;s not something that<br>
&gt; &gt; I&#39;d want to bother the people on cdi-dev with.<br>
&gt;<br>
&gt; Romain Manni-Bucau:<br>
&gt; &gt; Integrating it in CDI lifecycle through an event allow CDI users to still<br>
&gt; &gt; use it in the right phase of the container boot so it is still important<br>
&gt; &gt; IMO and avoid all users to have their own custom listener for it -<br>
&gt; &gt; @Initialized(AppScoped.class). Also allow to enrich the API through the<br>
&gt; event<br>
&gt; &gt; itself making things smoother IMO.<br>
&gt;<br>
&gt; Nigel:<br>
&gt; &gt; I&#39;m sorry I don&#39;t understand you.<br>
&gt; &gt; I thought you were asking about an API which does not use annotation.<br>
&gt;<br>
&gt; Romain Manni-Bucau:<br>
&gt; &gt; Both are needed (like websocket spec). Annotation one is nice for fully<br>
&gt; business<br>
&gt; &gt; code and/or simple libs but relying on CDI allows to simplify the wiring<br>
&gt; since you<br>
&gt; &gt; can reuse CDI beans under the hood ie have an implicit connection<br>
&gt; factory if<br>
&gt; &gt; there is a single one etc which is not possible in fully SE context.<br>
&gt;<br>
&gt; Can you explain the distinction you&#39;re making here? You seem to be<br>
&gt; suggesting two alternatives, using &quot;annotation&quot; and &quot;relying on CDI&quot;. What<br>
&gt; would an application which uses CDI but which doesn&#39;t use annotation look<br>
&gt; like?<br>
&gt;<br>
&gt;<br>
The sample I gave before with the JmsStart event basically:<br>
<br>
<br>
public class JmsRegistrar {<br>
    @Inject<br>
    @JmsConnectionFactory(...)<br>
    private ConnectionFactory factory;<br>
<br>
    @Inject<br>
    @JmsQueue(...)<br>
    private Queue queue;<br>
<br>
    public void startJms(@Observes JmsStart start) {<br>
        start.withFactory(factory) // withFactory should be optional if<br>
only 1 bean matches it<br>
               .register(MyCdiTypedListener.class) // with defaults for all<br>
potential config<br>
                   .listenOn(queue)<br>
               .register(MyCdiTypedListener2.class, new MyLiteral())<br>
                    .withMaxSessions(10)<br>
                    .listenOn(Queue.class, new QueueLiteral(...))<br>
                    ......;<br>
    }<br>
}<br>
<br>
<br>
The power of it appears when you have a config injection in JmsRegistrar<br>
you can iterate over to get the list of listener for instance.<br>
<br>
Also JMS resources can be decorated and referenced from qualifiers instead<br>
of instances thanks to CDI.<br>
<br>
It doesnt prevent the app to use @JmxListener somewhere else if the<br>
listener doesnt need any input/config to be registered.<br>
<br>
<br>
&gt; Nigel<br>
&gt;<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/attachment.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/attachment.html</a><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
End of cdi-dev Digest, Vol 57, Issue 21<br>
***************************************<br>
</blockquote></div><br></div></div></div>