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 (arjan tijms)
   2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
      EE application to listen for JMS messages (Werner Keil)
   3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
      EE application to listen for JMS messages (Jozef Hartinger)
   4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
      EE application to listen for JMS messages (Nigel Deakin)


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

Message: 3
Date: Wed, 26 Aug 2015 15:04:06 +0200
From: Jozef Hartinger <jharting@redhat.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>,     Romain Manni-Bucau
        <rmannibucau@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID: <55DDB946.9050208@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed

To me the proposed approach seems to be very strict about JMS semantics
and bending CDI over it (not using CDI contextual instances properly,
calling @RequestScoped instances from multiple threads in parallel, ..).

A simpler approach would be a bridge where a JMS message would produce a
single CDI event. The semantics of synchronous CDI events would apply
from there. For users this should be straightforward as they would know
that they are working with a CDI event that was raised by the container
when it received a JMS message.

Jozef


On 26.08.2015 11:43, Nigel Deakin wrote:
>  > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
>  >>
>  >> For this last case a really elegant solution would be to just reuse
>  >> @Observes to fire the message from the jms "container" listener and
>  >> propagate it to the "user" listener. This would then allow to decouple
>  >> the application listener from JMS.
>
> On 25/08/2015 15:26, Jozef Hartinger wrote:
>> Agreed. I think we should leverage the existing CDI event/observer
>> functionality instead of introducing a completely new
>> delivery mechanism.
>
> Can you please say a bit more about what you have in mind?
>
> Romain suggests using events to invoke the "user" listener from the "JMS
> container listener".
> That's a useful distinction. Just to clarify the terminology:
>
> "user" listener = listener bean provided by the application
> "JMS container listener" = JMS consumer provided by the application
> server or resource adapter
>
> There needs to be one consumer for every listener bean since the two
> need to have the same lifecycle, and also so we can implement JMS queue
> sematics which require that a message from a queue is delivered to one
> and only one listener.
>
> The transaction needs to be started by the consumer before invoking the
> listener and ended after the listener returns. This allows the
> acknowledgement of the message (which is performed by the consumer) to
> take place in the same transaction as is used by the listener's method.
>
> Currently I'm proposing that the "consumer" invokes the "listener" by a
> simple method call. I suppose instead of simply invoking the method it
> could fire a synchronous event, which only the associated listener
> instance would receive, but I'm not sure what the benefit of this would
> be. Since JMS semantics are very different from CDI event semantics I
> think there's a danger that this will be confusing, since the user might
> think they were getting CDI event semantics, but they were actually
> getting JMS semantics.
>
> Since this is a bit of a FAQ, it might be useful to explore the
> differences between the two semantics, but currently they seem
> profoundly different to me. That's why my proposals are built on the CDI
> bean lifecycle model but not the CDI event observer model.
>
> Nigel
>


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

Message: 4
Date: Wed, 26 Aug 2015 14:50:26 +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: arjan tijms <arjan.tijms@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID: <55DDC422.7000907@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 26/08/2015 13:26, arjan tijms wrote:
> Hi,
>
> On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <nigel.deakin@oracle.com> wrote:
>> In the case of a "JMS listener bean" with @RequestScoped (or any scope,
>> really) then the JMS consumer (the thread which receives a message from the
>> JMS server and invokes the listener) is associated with the actual bean
>> instance.
>
> Indeed, so the call takes place in the context of the JMS consumer
> thread and happens to the "bare" bean instance and does not go through
> the proxy that's normally used to access that bean.
>
>
>> However once you're inside the callback method then this request scope
>> (which relates to a different thread) is not available.
>
> So this would be an important detail for the user to take into
> account. The callback method is NOT allowed to access any other normal
> scoped beans, be it via injection, beanmanager lookup or whatever.
>
> E.g. given:
>
> @RequestScoped
> public class MyCDIBean21 {
>
>    @Inject
>    private MyRequestScopedBean requestBean;
>
>     @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
>     @JMSConnectionFactory("java:global/MyCF")
>     @MessageSelector("ticker='ORCL'")
>     public void processNewsItem(String newsItem) {
>       ...
>     }
>   }
>
> Then the callback processNewsItem() can not use requestBean, since
> it's a proxy and it will try to delegate to a scope that does not
> exist for that thread.
>
> Alternative, if there's an other @RequestScope active (as suggested
> below) it will end up calling a different bean instance than the user
> may expect.

Yes, I can see how that might be surprising.

However it looks as if this is exactly what is proposed in CDI 2.0 for asynchronous observer methods:

10.5.3 "Observer method invocation context" states "If the observer method is asynchronous, it is called in a new
lifecycle contexts, a new transaction context but the same security context as the invocation of Event.fireAsync()."

19.3.1. "Request context lifecycle in Java EE". States that "The request scope is active...during any asynchronous
invocation of an event observer".

Please correct me if I have misunderstood what is proposed.

> While it could work, I wonder if this aspect wouldn't be a bit confusing?

Good question!

Nigel


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

_______________________________________________
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 25
***************************************