<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("Message of wrong type: " + 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> <some other message data triggering a different booking event></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("invalid booking option");</div><div> break;</div><div> }</div><div> }</div></div><div><br></div><div>You'll get the idea about other types involved from the standard CDI example.<br><div class="gmail_extra">We'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"><<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a>></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 'help' 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 "Re: Contents of cdi-dev digest..."<br>
<br>
<br>
Today'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 <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><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 <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAE=-AhCnTyS-ZVAfT9k2jDK=<a href="mailto:k6QHW4ShUab_Vt%2Be6WmBN76gWg@mail.gmail.com">k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi,<br>
<br>
On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>> wrote:<br>
> On 25/08/2015 12:38, arjan tijms wrote:<br>
> 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's the small caveat that CDI itself doesn'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>
> then every time a new request starts, this event is fired which causes an<br>
> 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 <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><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 <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAE=-<a href="mailto:AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2%2BDQ@mail.gmail.com">AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi,<br>
<br>
On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>> wrote:<br>
> Someone over on the JMS user alias told me about this yesterday. So that<br>
> would avoid the need to call a method to trigger lazy initialisation on<br>
> normal-scoped bean proxies. I presume the application still has to inject<br>
> 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'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("Application scoped init!");<br>
}<br>
}<br>
<br>
Then you'll see "Application scoped init!" being printed in your<br>
server log when you deploy that application. No other code is needed.<br>
<br>
<br>
> If so then it sounds useful. Is it going to be included as a standard<br>
> feature of CDI 2.0? I see someone has proposed<br>
> <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 "IDs' it'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>
><br>
> Nigel<br>
><br>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 26 Aug 2015 10:11:21 +0200<br>
From: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><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 <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=<a href="mailto:SyQ@mail.gmail.com">SyQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2015-08-25 22:53 GMT+02:00 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>:<br>
<br>
> Hi,<br>
><br>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><br>
> wrote:<br>
> > On 25/08/2015 12:38, arjan tijms wrote:<br>
> > 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>
><br>
Events are not mandatory for a normal scope - at least was the case in 1.2<br>
- so JMS can't rely on it for custom normal scopes.<br>
<br>
<br>
> There's the small caveat that CDI itself doesn'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>
><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>
><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>
> > then every time a new request starts, this event is fired which causes an<br>
> > 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>
> 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<br>
> code under the Apache License, Version 2 (<br>
> <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>
> provided on this list, the provider waives all patent and other<br>
> intellectual property rights inherent in such information.<br>
><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 <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><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 <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID: <<a href="mailto:55DD81B5.9040407@oracle.com">55DD81B5.9040407@oracle.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
(Tidying up the top-posting...)<br>
<br>
Romain Manni-Bucau:<br>
> ...I see it really nice to not rely only on annotation - and aligned with<br>
> most specs - since sometimes you just want to either be able to rely on a<br>
> loop or a custom config to register your listeners. Annotations are too<br>
> rigid for such cases.<br>
<br>
Nigel:<br>
> Obviously, if users don't want to use CDI (or MDBs, which are also<br>
> declarative), then they would use the normal JMS API. The existing<br>
> API to register an async message listener isn't good enough,<br>
> and we may improve it in JMS 2.1, but that's not something that<br>
> I'd want to bother the people on cdi-dev with.<br>
<br>
Romain Manni-Bucau:<br>
> Integrating it in CDI lifecycle through an event allow CDI users to still<br>
> use it in the right phase of the container boot so it is still important<br>
> IMO and avoid all users to have their own custom listener for it -<br>
> @Initialized(AppScoped.class). Also allow to enrich the API through the event<br>
> itself making things smoother IMO.<br>
<br>
Nigel:<br>
> I'm sorry I don't understand you.<br>
> I thought you were asking about an API which does not use annotation.<br>
<br>
Romain Manni-Bucau:<br>
> Both are needed (like websocket spec). Annotation one is nice for fully business<br>
> code and/or simple libs but relying on CDI allows to simplify the wiring since you<br>
> can reuse CDI beans under the hood ie have an implicit connection factory if<br>
> there is a single one etc which is not possible in fully SE context.<br>
<br>
Can you explain the distinction you're making here? You seem to be suggesting two alternatives, using "annotation" and<br>
"relying on CDI". What would an application which uses CDI but which doesn'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 <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><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 <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAE=-<a href="mailto:AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com">AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com</a>><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>
<<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wrote:<br>
>> Yes, all normal scopes that are available in standard Java EE support<br>
>> this as far as I know.<br>
>><br>
><br>
> Events are not mandatory for a normal scope - at least was the case in 1.2 -<br>
> so JMS can'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 <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><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 <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=<a href="mailto:kL6gyb5jHb7fdA@mail.gmail.com">kL6gyb5jHb7fdA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2015-08-26 11:07 GMT+02:00 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>:<br>
<br>
> Hi,<br>
><br>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau<br>
> <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wrote:<br>
> >> Yes, all normal scopes that are available in standard Java EE support<br>
> >> this as far as I know.<br>
> >><br>
> ><br>
> > Events are not mandatory for a normal scope - at least was the case in<br>
> 1.2 -<br>
> > so JMS can'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>
><br>
Agree for provided scope but JMS + short time scopes will not match well in<br>
practise so i would worry more about not "default" scopes which can miss<br>
these events.<br>
<br>
<br>
> Kind regards,<br>
> Arjan Tijms<br>
><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 <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><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 <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CACLE=<a href="mailto:7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com">7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2015-08-26 11:07 GMT+02:00 Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>>:<br>
<br>
> (Tidying up the top-posting...)<br>
><br>
> Romain Manni-Bucau:<br>
> > ...I see it really nice to not rely only on annotation - and aligned with<br>
> > most specs - since sometimes you just want to either be able to rely on a<br>
> > loop or a custom config to register your listeners. Annotations are too<br>
> > rigid for such cases.<br>
><br>
> Nigel:<br>
> > Obviously, if users don't want to use CDI (or MDBs, which are also<br>
> > declarative), then they would use the normal JMS API. The existing<br>
> > API to register an async message listener isn't good enough,<br>
> > and we may improve it in JMS 2.1, but that's not something that<br>
> > I'd want to bother the people on cdi-dev with.<br>
><br>
> Romain Manni-Bucau:<br>
> > Integrating it in CDI lifecycle through an event allow CDI users to still<br>
> > use it in the right phase of the container boot so it is still important<br>
> > IMO and avoid all users to have their own custom listener for it -<br>
> > @Initialized(AppScoped.class). Also allow to enrich the API through the<br>
> event<br>
> > itself making things smoother IMO.<br>
><br>
> Nigel:<br>
> > I'm sorry I don't understand you.<br>
> > I thought you were asking about an API which does not use annotation.<br>
><br>
> Romain Manni-Bucau:<br>
> > Both are needed (like websocket spec). Annotation one is nice for fully<br>
> business<br>
> > code and/or simple libs but relying on CDI allows to simplify the wiring<br>
> since you<br>
> > can reuse CDI beans under the hood ie have an implicit connection<br>
> factory if<br>
> > there is a single one etc which is not possible in fully SE context.<br>
><br>
> Can you explain the distinction you're making here? You seem to be<br>
> suggesting two alternatives, using "annotation" and "relying on CDI". What<br>
> would an application which uses CDI but which doesn't use annotation look<br>
> like?<br>
><br>
><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>
> Nigel<br>
><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>