[cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
rmannibucau at gmail.com
Wed Aug 26 05:46:57 EDT 2015
Something I didnt think before but if you can register a method reference
then CDI event system starts to be useless:
can be something to investigate API wise maybe
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
2015-08-26 11:43 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
> > 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev