[cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages

[Jozef Hartinger]

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
>