[cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
jharting at redhat.com
Wed Aug 26 09:04:06 EDT 2015
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.
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.
More information about the cdi-dev