[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 26/08/2015 13:26, arjan tijms wrote:
> Hi,
>
> On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <nigel.deakin at 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