<div dir="ltr">well was thinking to both but I see it really nice to not rely only on annotation - and aligned with most specs - since sometimes you just want to either be able to rely on a loop or a custom config to register your listeners. Annotations are too rigid for such cases.</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-25 18:25 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">John,<br>
<br>
On 25/08/2015 16:31, John D. Ament wrote:<br>
<span class="">><br>
><br>
> On Tue, Aug 25, 2015 at 9:51 AM Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a> <mailto:<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>>> wrote:<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 register listeners?<br>
><br>
> The current proposal is is for the bean to start listening just as soon as 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 would call some method to tell it to start<br>
> listening? or did you have something else in mind?<br>
><br>
><br>
><br>
> Hmm, this would mean that only app scoped beans would apply?<br>
> It might be better to scan for the annotations and use that to start up the listener?<br>
<br>
</span>I was just making a guess at what you might had in mind by "manually register listeners".<br>
<span class="HOEnZb"><font color="#888888"><br>
Nigel<br>
</font></span><span class="im HOEnZb"><br>
<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 Java SE environment. I don't see why a similar<br>
> portable extension could not be created for use in Java SE. Since there would be no need to support Java EE behaviour<br>
> such as transactions this could be built directly on top of the JMS provider's Java SE client. No need to use a resource<br>
> adapter. However since the @JMSListener and @JMSConnectionFactory 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 at the moment, but it might perhaps be<br>
> something that we (the JMS expert group) could consider later on as a optional part of JMS 2.1.<br>
><br>
> There's also the Java EE application client to consider.<br>
><br>
> Nigel<br>
><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<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 under the Apache License, Version 2 (<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 provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
</div></div></blockquote></div><br></div>