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

Mon Aug 24 16:24:28 EDT 2015

Hi Nigel!

Glad to hear from you.  Was wondering, is there a way to manually register
listeners?  It would be great if this could be leveraged in a CDI SE
environment as well as EE environment.

John

On Mon, Aug 24, 2015 at 3:48 PM Nigel Deakin <nigel.deakin at oracle.com>
wrote:

> 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>
> 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>users at jms-spec.java.net alias.
>>
>> Thanks,
>>
>> Nigel
>> JMS 2.1 specification lead
>> _______________________________________________
>> cdi-dev mailing list
>> 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>
>> 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>
>
>
> _______________________________________________
> cdi-dev mailing list
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/171fd898/attachment.html 