<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div><div class="gmail_quote">2015-08-25 16:40 GMT+02:00 arjan tijms <span dir="ltr"><<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Tue, Aug 25, 2015 at 4:05 PM, Romain Manni-Bucau<br>
<<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wrote:<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 the<br>
> application listener from JMS.<br>
<br>
</span>That sounds great indeed.<br>
<br>
I'm very likely missing something though, but I wonder using that<br>
preferred approach how a message is exactly delivered to all instances<br>
of a bean in a given scope?<br>
<br>
E.g.<br>
<br>
Suppose the JMS listener bean is @SessionScoped, and there are<br>
currently 3 active sessions. The event is then fired from a system<br>
thread (I assume, but is this correct?). Can CDI find all of the 3<br>
active sessions and then call the observer method for separate<br>
instances of the bean in those 3 sessions?<br>
<br></blockquote><div><br></div><div>CDI not sure but CDI implementations can for sure find the instances, that said I hope it will be forbidden and that only scopes linked the a message context (ie app scoped, maybe singleton, dependent and jms scopes would be allowed. I am not yet clear is request scoped should be supported or if we need a wider scope because of JMS protocol)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or is this not how the feature is intended?<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
><br>
> For client side having a custom qualifier supporting placeholding - a bit<br>
> like jbatch for system properties - would be nice and would allow to skip<br>
> JNDI which means enabling SE usage as well.<br>
><br>
><br>
> Romain Manni-Bucau<br>
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber<br>
><br>
> 2015-08-25 15:51 GMT+02:00 Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>>:<br>
>><br>
>> On 24/08/2015 21:24, John D. Ament wrote:<br>
>> ><br>
>> > Hi Nigel!<br>
>> ><br>
>> > Glad to hear from you. Was wondering, is there a way to manually<br>
>> > register listeners?<br>
>><br>
>> The current proposal is is for the bean to start listening just as soon as<br>
>> it is created (by CDI), and for it to stop<br>
>> listening just before it is destroyed (by CDI).<br>
>><br>
>> As you suggesting that CDI would create the listener, but the application<br>
>> would call some method to tell it to start<br>
>> listening? or did you have something else in mind?<br>
>><br>
>> > It would be great if this could<br>
>> > be leveraged in a CDI SE environment as well as EE environment.<br>
>><br>
>> I see that work is underway for CDI 2.0 to define how CDI might work in a<br>
>> Java SE environment. I don't see why a similar<br>
>> portable extension could not be created for use in Java SE. Since there<br>
>> would be no need to support Java EE behaviour<br>
>> such as transactions this could be built directly on top of the JMS<br>
>> provider's Java SE client. No need to use a resource<br>
>> adapter. However since the @JMSListener and @JMSConnectionFactory<br>
>> annotations use JNDI there would be a need to be a way<br>
>> to specify which JNDI InitialContext to use. I'm not proposing any of this<br>
>> at the moment, but it might perhaps be<br>
>> something that we (the JMS expert group) could consider later on as a<br>
>> optional part of JMS 2.1.<br>
>><br>
>> There's also the Java EE application client to consider.<br>
>><br>
>> Nigel<br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses the<br>
>> code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> provided on this list, the provider waives all patent and other intellectual<br>
>> property rights inherent in such information.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code<br>
> under the Apache License, Version 2<br>
> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
> provided on this list, the provider waives all patent and other intellectual<br>
> property rights inherent in such information.<br>
</div></div></blockquote></div><br></div></div>