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

Nigel Deakin nigel.deakin at oracle.com
Tue Aug 25 12:25:46 EDT 2015


John,

On 25/08/2015 16:31, John D. Ament wrote:
>
>
> On Tue, Aug 25, 2015 at 9:51 AM Nigel Deakin <nigel.deakin at oracle.com <mailto:nigel.deakin at oracle.com>> wrote:
>
>     On 24/08/2015 21:24, John D. Ament wrote:
>      >
>      > Hi Nigel!
>      >
>      > Glad to hear from you.  Was wondering, is there a way to manually register listeners?
>
>     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
>     listening just before it is destroyed (by CDI).
>
>     As you suggesting that CDI would create the listener, but the application would call some method to tell it to start
>     listening? or did you have something else in mind?
>
>
>
> Hmm, this would mean that only app scoped beans would apply?
> It might be better to scan for the annotations and use that to start up the listener?

I was just making a guess at what you might had in mind by "manually register listeners".

Nigel


>
>       > It would be great if this could
>      > be leveraged in a CDI SE environment as well as EE environment.
>
>     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
>     portable extension could not be created for use in Java SE. Since there would be no need to support Java EE behaviour
>     such as transactions this could be built directly on top of the JMS provider's Java SE client. No need to use a resource
>     adapter. However since the @JMSListener and @JMSConnectionFactory annotations use JNDI there would be a need to be a way
>     to specify which JNDI InitialContext to use. I'm not proposing any of this at the moment, but it might perhaps be
>     something that we (the JMS expert group) could consider later on as a optional part of JMS 2.1.
>
>     There's also the Java EE application client to consider.
>
>     Nigel
>


More information about the cdi-dev mailing list