[cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
Werner Keil
werner.keil at gmail.com
Wed Aug 26 10:22:16 EDT 2015
Jozef,
Can't say to what extent this could also apply for JMS but just wanted to
point to the recent Portlet 3 draft
https://java.net/downloads/portletspec3/SpecDrafts/PortletSpec3-Draft1-20150821.pdf
(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.
Werner
On Wed, Aug 26, 2015 at 3:50 PM, <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at 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 at 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 at oracle.com>, Romain Manni-Bucau
> <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DDB946.9050208 at 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 at 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 at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DDC422.7000907 at 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 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
>
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 57, Issue 25
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/ce8efcae/attachment.html
More information about the cdi-dev
mailing list