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

[Nigel Deakin]

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 at oracle.com <mailto:nigel.deakin at 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 at jms-spec.java.net <mailto:users at jms-spec.java.net> alias.
>
>     Thanks,
>
>     Nigel
>     JMS 2.1 specification lead
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev at lists.jboss.org <mailto: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.
>
>
>
>
> -- 
> 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/attachment-0001.html