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

[arjan tijms]

Hi,

On Tue, Aug 25, 2015 at 4:05 PM, Romain Manni-Bucau
<rmannibucau at gmail.com> 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.

That sounds great indeed.

I'm very likely missing something though, but I wonder using that
preferred approach how a message is exactly delivered to all instances
of a bean in a given scope?

E.g.

Suppose the JMS listener bean is @SessionScoped, and there are
currently 3 active sessions. The event is then fired from a system
thread (I assume, but is this correct?). Can CDI find all of the 3
active sessions and then call the observer method for separate
instances of the bean in those 3 sessions?

Or is this not how the feature is intended?

Kind regards,
Arjan Tijms




>
> For client side having a custom qualifier supporting placeholding - a bit
> like jbatch for system properties - would be nice and would allow to skip
> JNDI which means enabling SE usage as well.
>
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>
> 2015-08-25 15:51 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
>>
>> 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?
>>
>>  > 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
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.