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@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@jms-spec.java.net alias.

Thanks,

Nigel
JMS 2.1 specification lead
_______________________________________________
cdi-dev mailing list
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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

_______________________________________________
cdi-dev mailing list
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.