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

[Romain Manni-Bucau]

2015-08-25 16:40 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> 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?
>
>
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)


> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/3bffc2ec/attachment-0001.html