<div dir="ltr">Something I didnt think before but if you can register a method reference then CDI event system starts to be useless:<div><br></div><div>xxx.register(myCdiBean::listenOn);</div><div><br></div><div>can be something to investigate API wise maybe</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2015-08-26 11:43 GMT+02:00 Nigel Deakin <span dir="ltr"><<a href="mailto:nigel.deakin@oracle.com" target="_blank">nigel.deakin@oracle.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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></span><span class="">
On 25/08/2015 15:26, Jozef Hartinger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Agreed. I think we should leverage the existing CDI event/observer functionality instead of introducing a completely new<br>
delivery mechanism.<br>
</blockquote>
<br></span>
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 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 server or resource adapter<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Nigel<br>
<br>
</font></span></blockquote></div><br></div>