Re: [cdi-dev] Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages

Send cdi-dev mailing list submissions to cdi-dev(a)lists.jboss.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.jboss.org/mailman/listinfo/cdi-dev or, via email, send a message with subject or body 'help' to cdi-dev-request(a)lists.jboss.org You can reach the person managing the list at cdi-dev-owner(a)lists.jboss.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cdi-dev digest..." Today's Topics: 1. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages (Antoine Sabot-Durand) 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages (Antonio Goncalves) 3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages (Nigel Deakin) ---------------------------------------------------------------------- Message: 1 Date: Mon, 24 Aug 2015 17:24:27 +0000 From: Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages To: Nigel Deakin <nigel.deakin(a)oracle.com&gt;, cdi-dev(a)lists.jboss.org Message-ID: <CABu-YBTqjtdMxbLO= TcFikN9XM-zgjfDP8Chhj5bqFSy6ueKOQ(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" Great Nigel, I'll have a look and try to give you feedback by the end of the week. Antoine Le lun. 24 ao?t 2015 ? 18:30, Nigel Deakin <nigel.deakin(a)oracle.com&gt; a ?crit : > Over in the JMS 2.1 expert group I've just published some proposals to > allow any CDI managed bean in a Java EE > application to listen for JMS messages. This would be implemented as a > standard CDI portable extension and would become > a mandatory part of a full Java EE 8 application server. > > I would welcome any comments from the CDI spec experts here. If you're > interested in helping, please take a look at > https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners > and send comments or questions to me or to the public > users(a)jms-spec.java.net alias. > > Thanks, > > Nigel > JMS 2.1 specification lead > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/1da85d2e/at... ------------------------------ Message: 2 Date: Mon, 24 Aug 2015 19:42:41 +0200 From: Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages To: Nigel Deakin <nigel.deakin(a)oracle.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <CA+ZZq9_Brvtks= jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" Nigel, what do you mean by : "The application must obtain an instance of the JMS listener bean using dependency injection" In your examples, it looks like a CDI bean cannot start listening if not injected : @WebServlet("/myjmsservlet1") public class MyJMSServlet1 extends HttpServlet { *@Inject MyDepScopeListenerBean* myDepScopeListenerBean; public void service(ServletRequest req, ServletResponse res) throws IOException, ServletException { ... } } Did I understand well ? Is this the case ? Just like a MDB, I would like a CDI bean to start listening to a message without being injected, as soon as the application starts. Something like : *@ApplicationScoped* public class MyListenerBean{ @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC ) public void deliver(Message message) { ... } } Or if we manage to get the @Startup annotation to Commons Annotation : *@Startup* public class MyListenerBean{ @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC ) public void deliver(Message message) { ... } } Just thinking here Antonio On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin(a)oracle.com&gt; wrote: > Over in the JMS 2.1 expert group I've just published some proposals to > allow any CDI managed bean in a Java EE > application to listen for JMS messages. This would be implemented as a > standard CDI portable extension and would become > a mandatory part of a full Java EE 8 application server. > > I would welcome any comments from the CDI spec experts here. If you're > interested in helping, please take a look at > https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners > and send comments or questions to me or to the public > users(a)jms-spec.java.net alias. > > Thanks, > > Nigel > JMS 2.1 specification lead > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn < http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/55f410a4/at... ------------------------------ Message: 3 Date: Mon, 24 Aug 2015 20:47:51 +0100 From: Nigel Deakin <nigel.deakin(a)oracle.com&gt; 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: Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <55DB74E7.4080609(a)oracle.com&gt; Content-Type: text/plain; charset="utf-8" On 24/08/2015 18:42, Antonio Goncalves wrote: > Nigel, what do you mean by : > > "The application must obtain an instance of the JMS listener bean using dependency injection" > > In your examples, it looks like a CDI bean cannot start listening if not injected : > > @WebServlet("/myjmsservlet1") > public class MyJMSServlet1 extends HttpServlet { > *@Inject MyDepScopeListenerBean* myDepScopeListenerBean; > public void service(ServletRequest req, ServletResponse res) throws IOException, ServletException { > ... > } > } > > > Did I understand well ? Is this the case ? Just like a MDB, I would like a CDI bean to start listening to a message > without being injected, as soon as the application starts. My starting point is that these are normal CDI beans which are created just like any other CDI bean. The bean's postCreate behaviour (inserted by the extension) would connect to the JMS provider and start listening for messages. The bean's preDestroy behaviour would stop listening for messages and disconnect from the JMS provider. As I understand it, if you want to create a CDI managed bean (so that it is managed by CDI) then you have to inject it into some code somewhere. Additionally, if the bean is normal scoped, you have to trigger lazy instantiation by calling a method on the injected bean proxy (e.g. toString()). > Something like : > > *@ApplicationScoped* > public class MyListenerBean{ > @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC ) > public void deliver(Message message) { > ... > } > } > If I understand things correctly, if this is a normal CDI bean then this alone is not sufficient to cause an instance of the bean to be created. You also need to (1) inject it into some other bean (2) create that other bean and (3) call a method on the MyListenerBean to trigger lazy initialisation. I'm trying to avoid getting ahead of myself here. My current proposals simply apply to normal CDI managed beans created in the normal way (via injection and lazy initialisation). But I could certainly see a benefit in extending this to allow JMS listener beans to be created in other ways. In particular: (a) Creating the bean instance as soon as the bean into which it is injected enters a new scope rather than waiting for the application to call a method on it (so-called eager initialisation). That sounds relatively straightforward to me; this could either be a new standard CDI feature available to all normal-scoped beans, or something specific to beans annotated with @JMSListener. (b) Creating the bean instance without the need to inject it anywhere. As you suggest, in the case of ApplicationScoped beans this would make JMS listener beans more like MDBs. But it might be equally useful to support this for other normal scopes. For example, could we annotate a @RequestScoped bean so that every time a new request scope started, an instance of the bean for that scope was automatically created? > Or if we manage to get the @Startup annotation to Commons Annotation : > > *@Startup* > public class MyListenerBean{ > @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC ) > public void deliver(Message message) { > ... > } > } > That looks as if it's tied to ApplicationScoped. I'd rather look for something more general. Thanks for your comments so far. You're raising issues I have been thinking about for some time. Nigel > > Just thinking here > > Antonio > > On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin(a)oracle.com <mailto:nigel.deakin@oracle.com>> wrote: > > Over in the JMS 2.1 expert group I've just published some proposals to allow any CDI managed bean in a Java EE > application to listen for JMS messages. This would be implemented as a standard CDI portable extension and would > become > a mandatory part of a full Java EE 8 application server. > > I would welcome any comments from the CDI spec experts here. If you're interested in helping, please take a look at > https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners > and send comments or questions to me or to the public users(a)jms-spec.java.net <mailto:users@jms-spec.java.net> alias. > > Thanks, > > Nigel > JMS 2.1 specification lead > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site <http://www.antoniogoncalves.org> | Twitter < http://twitter.com/agoncal> | LinkedIn > <http://www.linkedin.com/in/agoncal> | Pluralsight > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx > France <http://www.devoxx.fr> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/86151522/at... ------------------------------ _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. End of cdi-dev Digest, Vol 57, Issue 13 ***************************************