<div dir="ltr">Jozef,<div><br></div><div>Can't say to what extent this could also apply for JMS but just wanted to point to the recent Portlet 3 draft <a href="https://java.net/downloads/portletspec3/SpecDrafts/PortletSpec3-Draft1-20150821.pdf">https://java.net/downloads/portletspec3/SpecDrafts/PortletSpec3-Draft1-20150821.pdf</a> (20.2 Custom Scopes) where the JSR intends to add new CDI scopes for certain parts of the standard while using the ones Java EE/CDI defines in other cases.</div><div><br></div><div><span lang="EN-US" style="font-size:13px;font-family:Calibri">Werner</span></div><div><div class="gmail_extra">
<br><div class="gmail_quote">On Wed, Aug 26, 2015 at 3:50 PM, <span dir="ltr"><<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send cdi-dev mailing list submissions to<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cdi-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (arjan tijms)<br>
2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (Werner Keil)<br>
3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (Jozef Hartinger)<br>
4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (Nigel Deakin)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>Message: 3<br>
Date: Wed, 26 Aug 2015 15:04:06 +0200<br>
From: Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>><br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
in a Java EE application to listen for JMS messages<br>
To: Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>>, Romain Manni-Bucau<br>
<<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID: <<a href="mailto:55DDB946.9050208@redhat.com">55DDB946.9050208@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
To me the proposed approach seems to be very strict about JMS semantics<br>
and bending CDI over it (not using CDI contextual instances properly,<br>
calling @RequestScoped instances from multiple threads in parallel, ..).<br>
<br>
A simpler approach would be a bridge where a JMS message would produce a<br>
single CDI event. The semantics of synchronous CDI events would apply<br>
from there. For users this should be straightforward as they would know<br>
that they are working with a CDI event that was raised by the container<br>
when it received a JMS message.<br>
<br>
Jozef<br>
<br>
<br>
On 26.08.2015 11:43, Nigel Deakin wrote:<br>
> > On 25.08.2015 16:05, Romain Manni-Bucau wrote:<br>
> >><br>
> >> For this last case a really elegant solution would be to just reuse<br>
> >> @Observes to fire the message from the jms "container" listener and<br>
> >> propagate it to the "user" listener. This would then allow to decouple<br>
> >> the application listener from JMS.<br>
><br>
> On 25/08/2015 15:26, Jozef Hartinger wrote:<br>
>> Agreed. I think we should leverage the existing CDI event/observer<br>
>> functionality instead of introducing a completely new<br>
>> delivery mechanism.<br>
><br>
> Can you please say a bit more about what you have in mind?<br>
><br>
> Romain suggests using events to invoke the "user" listener from the "JMS<br>
> container listener".<br>
> That's a useful distinction. Just to clarify the terminology:<br>
><br>
> "user" listener = listener bean provided by the application<br>
> "JMS container listener" = JMS consumer provided by the application<br>
> server or resource adapter<br>
><br>
> There needs to be one consumer for every listener bean since the two<br>
> need to have the same lifecycle, and also so we can implement JMS queue<br>
> sematics which require that a message from a queue is delivered to one<br>
> and only one listener.<br>
><br>
> The transaction needs to be started by the consumer before invoking the<br>
> listener and ended after the listener returns. This allows the<br>
> acknowledgement of the message (which is performed by the consumer) to<br>
> take place in the same transaction as is used by the listener's method.<br>
><br>
> Currently I'm proposing that the "consumer" invokes the "listener" by a<br>
> simple method call. I suppose instead of simply invoking the method it<br>
> could fire a synchronous event, which only the associated listener<br>
> instance would receive, but I'm not sure what the benefit of this would<br>
> be. Since JMS semantics are very different from CDI event semantics I<br>
> think there's a danger that this will be confusing, since the user might<br>
> think they were getting CDI event semantics, but they were actually<br>
> getting JMS semantics.<br>
><br>
> Since this is a bit of a FAQ, it might be useful to explore the<br>
> differences between the two semantics, but currently they seem<br>
> profoundly different to me. That's why my proposals are built on the CDI<br>
> bean lifecycle model but not the CDI event observer model.<br>
><br>
> Nigel<br>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 26 Aug 2015 14:50:26 +0100<br>
From: Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
in a Java EE application to listen for JMS messages<br>
To: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID: <<a href="mailto:55DDC422.7000907@oracle.com">55DDC422.7000907@oracle.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 26/08/2015 13:26, arjan tijms wrote:<br>
> Hi,<br>
><br>
> On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>> wrote:<br>
>> In the case of a "JMS listener bean" with @RequestScoped (or any scope,<br>
>> really) then the JMS consumer (the thread which receives a message from the<br>
>> JMS server and invokes the listener) is associated with the actual bean<br>
>> instance.<br>
><br>
> Indeed, so the call takes place in the context of the JMS consumer<br>
> thread and happens to the "bare" bean instance and does not go through<br>
> the proxy that's normally used to access that bean.<br>
><br>
><br>
>> However once you're inside the callback method then this request scope<br>
>> (which relates to a different thread) is not available.<br>
><br>
> So this would be an important detail for the user to take into<br>
> account. The callback method is NOT allowed to access any other normal<br>
> scoped beans, be it via injection, beanmanager lookup or whatever.<br>
><br>
> E.g. given:<br>
><br>
> @RequestScoped<br>
> public class MyCDIBean21 {<br>
><br>
> @Inject<br>
> private MyRequestScopedBean requestBean;<br>
><br>
> @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC<br>
> )<br>
> @JMSConnectionFactory("java:global/MyCF")<br>
> @MessageSelector("ticker='ORCL'")<br>
> public void processNewsItem(String newsItem) {<br>
> ...<br>
> }<br>
> }<br>
><br>
> Then the callback processNewsItem() can not use requestBean, since<br>
> it's a proxy and it will try to delegate to a scope that does not<br>
> exist for that thread.<br>
><br>
> Alternative, if there's an other @RequestScope active (as suggested<br>
> below) it will end up calling a different bean instance than the user<br>
> may expect.<br>
<br>
Yes, I can see how that might be surprising.<br>
<br>
However it looks as if this is exactly what is proposed in CDI 2.0 for asynchronous observer methods:<br>
<br>
10.5.3 "Observer method invocation context" states "If the observer method is asynchronous, it is called in a new<br>
lifecycle contexts, a new transaction context but the same security context as the invocation of Event.fireAsync()."<br>
<br>
19.3.1. "Request context lifecycle in Java EE". States that "The request scope is active...during any asynchronous<br>
invocation of an event observer".<br>
<br>
Please correct me if I have misunderstood what is proposed.<br>
<br>
> While it could work, I wonder if this aspect wouldn't be a bit confusing?<br>
<br>
Good question!<br>
<br>
Nigel<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
End of cdi-dev Digest, Vol 57, Issue 25<br>
***************************************<br>
</blockquote></div><br></div></div></div>