4:40 p.m.
Hi,
On Tue, Aug 25, 2015 at 4:05 PM, Romain Manni-Bucau
<rmannibucau(a)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(a)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(a)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(a)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.