Antoine/Nigel/all,

Sounds very interesting (especially being in both EGs) 
Although the project situation ended up with a more synchronous requirement, I did something very similar as a prototype relaying an MDB's onMessage() to a CDI event;-)

Would be great to get something like that standardized.

Werner


On Mon, Aug 24, 2015 at 9:48 PM, <cdi-dev-request@lists.jboss.org> wrote:

Send cdi-dev mailing list submissions to
        cdi-dev@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@lists.jboss.org

You can reach the person managing the list at
        cdi-dev-owner@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@sabot-durand.net>
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@oracle.com>, cdi-dev@lists.jboss.org
Message-ID:
        <CABu-YBTqjtdMxbLO=TcFikN9XM-zgjfDP8Chhj5bqFSy6ueKOQ@mail.gmail.com>
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@oracle.com> 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@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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/1da85d2e/attachment-0001.html

------------------------------

Message: 2
Date: Mon, 24 Aug 2015 19:42:41 +0200
From: Antonio Goncalves <antonio.goncalves@gmail.com>
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@oracle.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
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@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 <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/attachment-0001.html

------------------------------

Message: 3
Date: Mon, 24 Aug 2015 20:47:51 +0100
From: Nigel Deakin <nigel.deakin@oracle.com>
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@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID: <55DB74E7.4080609@oracle.com>
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@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@jms-spec.java.net <mailto:users@jms-spec.java.net> alias.
>
>     Thanks,
>
>     Nigel
>     JMS 2.1 specification lead
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev@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/attachment.html

------------------------------

_______________________________________________
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.

End of cdi-dev Digest, Vol 57, Issue 13
***************************************