[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:43 PM, Romain Manni-Bucau
<rmannibucau at gmail.com> wrote:
> 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.

This was one of my biggest questions when reading the proposal. It now
explicitly mentions @RequestScoped beans
(https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners#CDI_managed_listener_bean_with_request_scope).

With the proposed mechanism where a bean instance itself (invisibly)
connects to the location from where the JMS messages originate, this
would be somewhat doable, but it's not exactly how CDI events normally
work.

> I am not yet clear is request scoped should be supported or if we
> need a wider scope because of JMS protocol)

That's a good question.

Kind regards,
Arjan Tijms



>
>>
>> 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.
>
>