Over in the JMS 2.1 expert group I've just published some proposals to allow any CDI managed bean in a Java EE application to listen for JMS messages. This would be implemented as a standard CDI portable extension and would become a mandatory part of a full Java EE 8 application server. I would welcome any comments from the CDI spec experts here. If you're interested in helping, please take a look at https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners and send comments or questions to me or to the public users(a)jms-spec.java.net alias. Thanks, Nigel JMS 2.1 specification lead _______________________________________________ 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.

Nigel, what do you mean by : "The application must obtain an instance of the JMS listener bean using dependency injection" In your examples, it looks like a CDI bean cannot start listening if not injected : @WebServlet("/myjmsservlet1") public class MyJMSServlet1 extends HttpServlet { *@Inject MyDepScopeListenerBean* myDepScopeListenerBean; public void service(ServletRequest req, ServletResponse res) throws IOException, ServletException { ... } } Did I understand well ? Is this the case ? Just like a MDB, I would like a CDI bean to start listening to a message without being injected, as soon as the application starts.

Something like : *@ApplicationScoped* public class MyListenerBean{ @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC ) public void deliver(Message message) { ... } }

Or if we manage to get the @Startup annotation to Commons Annotation : *@Startup* public class MyListenerBean{ @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC ) public void deliver(Message message) { ... } }

Just thinking here Antonio On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin(a)oracle.com <mailto:nigel.deakin@oracle.com>> wrote: Over in the JMS 2.1 expert group I've just published some proposals to allow any CDI managed bean in a Java EE application to listen for JMS messages. This would be implemented as a standard CDI portable extension and would become a mandatory part of a full Java EE 8 application server. I would welcome any comments from the CDI spec experts here. If you're interested in helping, please take a look at https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners and send comments or questions to me or to the public users(a)jms-spec.java.net <mailto:users@jms-spec.java.net> alias. Thanks, Nigel JMS 2.1 specification lead _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>

Hi Nigel! Glad to hear from you. Was wondering, is there a way to manually register listeners?

It would be great if this could be leveraged in a CDI SE environment as well as EE environment.

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.

> On 25.08.2015 16:05, Romain Manni-Bucau 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. On 25/08/2015 15:26, Jozef Hartinger wrote: > Agreed. I think we should leverage the existing CDI event/observer > functionality instead of introducing a completely new > delivery mechanism. > Can you please say a bit more about what you have in mind? Romain suggests using events to invoke the "user" listener from the "JMS container listener". That's a useful distinction. Just to clarify the terminology: "user" listener = listener bean provided by the application "JMS container listener" = JMS consumer provided by the application server or resource adapter There needs to be one consumer for every listener bean since the two need to have the same lifecycle, and also so we can implement JMS queue sematics which require that a message from a queue is delivered to one and only one listener. The transaction needs to be started by the consumer before invoking the listener and ended after the listener returns. This allows the acknowledgement of the message (which is performed by the consumer) to take place in the same transaction as is used by the listener's method. Currently I'm proposing that the "consumer" invokes the "listener" by a simple method call. I suppose instead of simply invoking the method it could fire a synchronous event, which only the associated listener instance would receive, but I'm not sure what the benefit of this would be. Since JMS semantics are very different from CDI event semantics I think there's a danger that this will be confusing, since the user might think they were getting CDI event semantics, but they were actually getting JMS semantics. Since this is a bit of a FAQ, it might be useful to explore the differences between the two semantics, but currently they seem profoundly different to me. That's why my proposals are built on the CDI bean lifecycle model but not the CDI event observer model. Nigel

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.

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&gt;: > > 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.

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(a)oracle.com&gt;: > >> > >> 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.

On Tue, Aug 25, 2015 at 9:51 AM Nigel Deakin <nigel.deakin(a)oracle.com&gt; 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?

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

John, On 25/08/2015 16:31, John D. Ament wrote: > > > On Tue, Aug 25, 2015 at 9:51 AM Nigel Deakin <nigel.deakin(a)oracle.com <mailto:nigel.deakin@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 > _______________________________________________ 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.

On 25/08/2015 17:35, Romain Manni-Bucau wrote: > well was thinking to both but I see it really nice to not rely only on > annotation - and aligned with most specs - since > sometimes you just want to either be able to rely on a loop or a custom > config to register your listeners. Annotations > are too rigid for such cases. > Obviously, if users don't want to use CDI (or MDBs, which are also declarative), then they would use the normal JMS API. The existing API to register an async message listener isn't good enough, and we may improve it in JMS 2.1, but that's not something that I'd want to bother the people on cdi-dev with. Nigel

I'm sorry I don't understand you. I thought you were asking about an API which does not use annotation.

Nigel On 25/08/2015 18:03, Romain Manni-Bucau wrote: > Integrating it in CDI lifecycle through an event allow CDI users to still > use it in the right phase of the container > boot so it is still important IMO and avoid all users to have their own > custom listener for it - > @Initialized(AppScoped.class). Also allow to enrich the API through the > event itself making things smoother IMO. > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog < > http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn < > https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-08-25 18:58 GMT+02:00 Nigel Deakin <nigel.deakin(a)oracle.com <mailto: > nigel.deakin(a)oracle.com&gt;&gt;: > > On 25/08/2015 17:35, Romain Manni-Bucau wrote: > > well was thinking to both but I see it really nice to not rely > only on annotation - and aligned with most specs > - since > sometimes you just want to either be able to rely on a loop or a > custom config to register your listeners. > Annotations > are too rigid for such cases. > > > Obviously, if users don't want to use CDI (or MDBs, which are also > declarative), then they would use the normal JMS > API. The existing API to register an async message listener isn't > good enough, and we may improve it in JMS 2.1, but > that's not something that I'd want to bother the people on cdi-dev > with. > > Nigel > > >

(Tidying up the top-posting...) Romain Manni-Bucau: > ...I see it really nice to not rely only on annotation - and aligned with > most specs - since sometimes you just want to either be able to rely on a > loop or a custom config to register your listeners. Annotations are too > rigid for such cases. Nigel: > Obviously, if users don't want to use CDI (or MDBs, which are also > declarative), then they would use the normal JMS API. The existing > API to register an async message listener isn't good enough, > and we may improve it in JMS 2.1, but that's not something that > I'd want to bother the people on cdi-dev with. Romain Manni-Bucau: > Integrating it in CDI lifecycle through an event allow CDI users to still > use it in the right phase of the container boot so it is still important > IMO and avoid all users to have their own custom listener for it - > @Initialized(AppScoped.class). Also allow to enrich the API through the event > itself making things smoother IMO. Nigel: > I'm sorry I don't understand you. > I thought you were asking about an API which does not use annotation. Romain Manni-Bucau: > Both are needed (like websocket spec). Annotation one is nice for fully business > code and/or simple libs but relying on CDI allows to simplify the wiring since you > can reuse CDI beans under the hood ie have an implicit connection factory if > there is a single one etc which is not possible in fully SE context. Can you explain the distinction you're making here? You seem to be suggesting two alternatives, using "annotation" and "relying on CDI". What would an application which uses CDI but which doesn't use annotation look like?

Nigel

On 26/08/2015 10:16, Romain Manni-Bucau wrote: > > > The sample I gave before with the JmsStart event basically: > > > public class JmsRegistrar { > @Inject > @JmsConnectionFactory(...) > private ConnectionFactory factory; > > @Inject > @JmsQueue(...) > private Queue queue; > > public void startJms(@Observes JmsStart start) { > start.withFactory(factory) // withFactory should be optional if > only 1 bean matches it > .register(MyCdiTypedListener.class) // with defaults for > all potential config > .listenOn(queue) > .register(MyCdiTypedListener2.class, new MyLiteral()) > .withMaxSessions(10) > .listenOn(Queue.class, new QueueLiteral(...)) > ......; > } > } > > > The power of it appears when you have a config injection in JmsRegistrar > you can iterate over to get the list of > listener for instance. > > Also JMS resources can be decorated and referenced from qualifiers > instead of instances thanks to CDI. > > It doesnt prevent the app to use @JmxListener somewhere else if the > listener doesnt need any input/config to be registered. > > I'm trying to understand this. Are you suggesting that 1. When the application is started an event of type JmsStart is fired. This class will be defined by JMS and implemented by the application server. 2. The application defines a class (in this example called JmsRegistrar). This has a method startJms which receives the event. 3. JmsStart (the event class) has several builder methods. The most important of these is register() which you can use to specify the class of a listener. The other methods withFactory, register, withMaxSession and listenOn specify things like which connection factory is used, which queue is used and so on. This doesn't look very different from the normal JMS API, except that it uses a builder pattern and is triggered automatically at startup. Apart from triggering the initial event, what is CDI doing for you here?

Nigel

On 27/08/2015 16:35, Romain Manni-Bucau wrote: > > 2015-08-27 17:31 GMT+02:00 Nigel Deakin <nigel.deakin(a)oracle.com <mailto: > nigel.deakin(a)oracle.com&gt;&gt;: > > > On 26/08/2015 10:16, Romain Manni-Bucau wrote: > > > > The sample I gave before with the JmsStart event basically: > > > public class JmsRegistrar { > @Inject > @JmsConnectionFactory(...) > private ConnectionFactory factory; > > @Inject > @JmsQueue(...) > private Queue queue; > > public void startJms(@Observes JmsStart start) { > start.withFactory(factory) // withFactory should be > optional if only 1 bean matches it > .register(MyCdiTypedListener.class) // with > defaults for all potential config > .listenOn(queue) > .register(MyCdiTypedListener2.class, new > MyLiteral()) > .withMaxSessions(10) > .listenOn(Queue.class, new > QueueLiteral(...)) > ......; > } > } > > > The power of it appears when you have a config injection in > JmsRegistrar you can iterate over to get the list of > listener for instance. > > Also JMS resources can be decorated and referenced from > qualifiers instead of instances thanks to CDI. > > It doesnt prevent the app to use @JmxListener somewhere else if > the listener doesnt need any input/config to be > registered. > > > I'm trying to understand this. Are you suggesting that > > 1. When the application is started an event of type JmsStart is > fired. This class will be defined by JMS and > implemented by the application server. > > 2. The application defines a class (in this example called > JmsRegistrar). This has a method startJms which receives > the event. > > 3. JmsStart (the event class) has several builder methods. The most > important of these is register() which you can > use to specify the class of a listener. The other methods > withFactory, register, withMaxSession and listenOn specify > things like which connection factory is used, which queue is used and > so on. > > This doesn't look very different from the normal JMS API, except that > it uses a builder pattern and is triggered > automatically at startup. Apart from triggering the initial event, > what is CDI doing for you here? > > > Yes this is it, few details important for CDI: > > 1- ensure JMS is CDI ready - ie dont use it before the start event, if > JMS uses @Initialized(ApplicationScoped) then the > app cant use it for instance, same using extension > AfterValidationDeployment etc...so this event is just to ensure we > dont use "JMS CDI" too early > 2- JMS can use contextual instances implicitely which is not the case in > SE > > otherwise you are right the API is just fluent compared to what is > already there - found it nicer to expose but this > point is maybe personal. > OK. I'm interested in your statement "JMS can use contextual instances implicitly". That suggests that the method register(MyCdiTypedListener.class) would use some CDI API such as Instance.get() to obtain an instance of MyCdiTypedListener rather than simply using new. Is that right?

What I can't see yet is how to pass in the configuration parameters for specifying things like the queue. These are not qualifiers which are used by Instance.select() to determine which class is instantiated. They are values which are used by the bean's postConstruct method (as extended by the portable extension) to initialise the bean.

Nigel

Hi, On Mon, Aug 24, 2015 at 9:47 PM, Nigel Deakin <nigel.deakin(a)oracle.com&gt; wrote: > As I understand it, if you want to create a CDI managed bean (so that it is > managed by CDI) then you have to inject it into some code somewhere. This is not exclusively the case really; There are generally 3 options: 1. Bean is injected 2. Bean is named (using @Named annotation or getName() of a Bean<T> returns non null) and referenced by EL 3. Bean is programmatically created via BeanManager In saw that the proposal essentially has an example of 3. already; using the Instance injection. There are 2 variants on this where code either uses the BeanManager directly or uses the "shortcut" CDI.current().select(...); Option 3. is often used when something needs a bean of a specific type to do something. E.g. in JSF 2.3 a user would define a bean like this: @FacesDataModel(forClass = MyCollection.class) public class MyCollectionModel<E> extends DataModel<E> { ... } And it just sits there (the user doesn't have to create it). When a component needs this, it tries to obtain it programmatically, via something like: cdi.select( DataModel.class, new FacesDataModelAnnotationLiteral(MyCollection.class) ).get(); So the *expectation* may be that a user just defines a CDI based JMS listener bean, and that the container will then find those beans when it needs to deliver a message. Of course this is not entirely trivial in the JMS listener case. The JMS runtime can not easily ask CDI for all active instances of say the request scope, and then ask for beans to be created in all those scopes and then deliver the message to all of them. > If I understand things correctly, if this is a normal CDI bean then this > alone is not sufficient to cause an instance of the bean to be created. > > You also need to > (1) inject it into some other bean > (2) create that other bean and > (3) call a method on the MyListenerBean to trigger lazy initialisation. This is one way for sure, but one alternative worth mentioning is to eagerly instantiatie the scoped bean whenever its scope starts. For OmniFaces we have implemented a separate annotation for this for CDI 1.0, see http://showcase.omnifaces.org/cdi/Eager For CDI 1.1, there's the @Initialized and @Destroyed annotations that can be used to observe any scope where the implementing Context throws events for these (which are all Java EE provided scopes as far as I know). See https://rmannibucau.wordpress.com/2015/03/10/cdi-and-startup and https://issues.jboss.org/browse/CDI-86 One CDI technicality is that if the listener method is called via the proxy, I think it will resolve to the current scope that thread is in. So this may mean the JMS endpoint that calls the JMS listener bean can only call the actual bean's method, not the proxied one. I'm sure the CDI experts here will have more knowledge about this. Hope this helps. Kind regards, Arjan Tijms > > I'm trying to avoid getting ahead of myself here. My current proposals > simply apply to normal CDI managed beans created in the normal way (via > injection and lazy initialisation). But I could certainly see a benefit in > extending this to allow JMS listener beans to be created in other ways. In > particular: > > (a) Creating the bean instance as soon as the bean into which it is injected > enters a new scope rather than waiting for the application to call a method > on it (so-called eager initialisation). That sounds relatively > straightforward to me; this could either be a new standard CDI feature > available to all normal-scoped beans, or something specific to beans > annotated with @JMSListener. > > (b) Creating the bean instance without the need to inject it anywhere. As > you suggest, in the case of ApplicationScoped beans this would make JMS > listener beans more like MDBs. But it might be equally useful to support > this for other normal scopes. For example, could we annotate a > @RequestScoped bean so that every time a new request scope started, an > instance of the bean for that scope was automatically created? > > Or if we manage to get the @Startup annotation to Commons Annotation : > > @Startup > public class MyListenerBean{ > > > @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC > ) > public void deliver(Message message) { > ... > } > } > > > That looks as if it's tied to ApplicationScoped. I'd rather look for > something more general. > > Thanks for your comments so far. You're raising issues I have been thinking > about for some time. > > Nigel > > > > > Just thinking here > > Antonio > > On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin(a)oracle.com&gt; > wrote: >> >> Over in the JMS 2.1 expert group I've just published some proposals to >> allow any CDI managed bean in a Java EE >> application to listen for JMS messages. This would be implemented as a >> standard CDI portable extension and would become >> a mandatory part of a full Java EE 8 application server. >> >> I would welcome any comments from the CDI spec experts here. If you're >> interested in helping, please take a look at >> https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners >> and send comments or questions to me or to the public >> users(a)jms-spec.java.net alias. >> >> Thanks, >> >> Nigel >> JMS 2.1 specification lead >> _______________________________________________ >> 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. > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > _______________________________________________ > 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.

On Tue, Aug 25, 2015 at 1:19 PM, John D. Ament <john.d.ament(a)gmail.com&gt; wrote: > Technically speaking, I can have a bean like this: > > @ApplicationScoped > public class Foo { > public void onStart(@Observes @initialized(ApplicationScoped.class) > Object obj) { > // do some work here > } > } > > That bean will get instantiated by the container, even if it doesn't have > any injection targets. Indeed, that's what I meant above with the reference to the @Initialized and @Destroyed annotations. With that construct a JMS Listener bean can be "started" without it having to be referenced from other code.

Hi, On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin(a)oracle.com&gt; wrote: > On 25/08/2015 12:38, arjan tijms wrote: > This looks very interesting. Does this work with any normal scope? Yes, all normal scopes that are available in standard Java EE support this as far as I know.

There's the small caveat that CDI itself doesn't know about this automatically for any custom normal scope. That implementation of such scope (via a Context) must explicitly throw these events. For example, this is what Mojarra does for the @FlowScoped implementation: https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com... Which is fired when the scope starts here: https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com... (the exact same code is used for @ViewScoped in Mojarra as well) > then every time a new request starts, this event is fired which causes an > instance of the bean to be created for that request? Yes, that is what this does ;) Kind regards, Arjan Tijms _______________________________________________ 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.

Hi, On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: >> Yes, all normal scopes that are available in standard Java EE support >> this as far as I know. >> > > Events are not mandatory for a normal scope - at least was the case in 1.2 - > so JMS can't rely on it for custom normal scopes. Absolutely true, but that was exactly what I said ;) All Java EE provided scopes throw the events. For CDI, this is mandated by the spec (6.7) for @RequestScoped, @SessionScoped, @ApplicationScoped and @ConversationScoped. For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I have to double check whether this is actually in the spec for those last two and if not see if we can update it for 2.3.

Kind regards, Arjan Tijms

On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: > Agree for provided scope but JMS + short time scopes will not match well in > practise so i would worry more about not "default" scopes which can miss > these events. Short lived scopes like @RequestScoped may not be the best match indeed. Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped" thing, e.g. there's the expectation that only the current thread will access it. If the JMS provider will asynchronously call a method on the bean instance from another thread, then this breaks this assumption.

The JMS provider would be responsible for retrieving a contextual reference to the bean and then invoking the method.

On Wed, Aug 26, 2015 at 6:53 AM Nigel Deakin <nigel.deakin(a)oracle.com <mailto:nigel.deakin@oracle.com>> wrote: On 26/08/2015 10:51, arjan tijms wrote: > On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau > <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: >> Agree for provided scope but JMS + short time scopes will not match well in >> practise so i would worry more about not "default" scopes which can miss >> these events. > > Short lived scopes like @RequestScoped may not be the best match indeed. > > Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped" > thing, e.g. there's the expectation that only the current thread will > access it. If the JMS provider will asynchronously call a method on > the bean instance from another thread, then this breaks this > assumption. That's an interesting point. Is there anything in the CDI spec which would forbid the use of a @RequestScoped JMS listener bean from another thread? The CDI spec still mandates that a request scope is started for delivery to MDBs. See http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_context The JMS provider would be responsible for retrieving a contextual reference to the bean and then invoking the method. The container should still be responsible for starting the request context (If I read this correctly).

Likewise, we could say that a @TransactionScoped bean also applies here, since a JTA transaction should have been started by the RA.

Hi, On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <nigel.deakin(a)oracle.com&gt; wrote: > In the case of a "JMS listener bean" with @RequestScoped (or any scope, > really) then the JMS consumer (the thread which receives a message from the > JMS server and invokes the listener) is associated with the actual bean > instance. Indeed, so the call takes place in the context of the JMS consumer thread and happens to the "bare" bean instance and does not go through the proxy that's normally used to access that bean. > However once you're inside the callback method then this request scope > (which relates to a different thread) is not available. So this would be an important detail for the user to take into account. The callback method is NOT allowed to access any other normal scoped beans, be it via injection, beanmanager lookup or whatever. E.g. given: @RequestScoped public class MyCDIBean21 { @Inject private MyRequestScopedBean requestBean; @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC ) @JMSConnectionFactory("java:global/MyCF") @MessageSelector("ticker='ORCL'") public void processNewsItem(String newsItem) { ... } } Then the callback processNewsItem() can not use requestBean, since it's a proxy and it will try to delegate to a scope that does not exist for that thread. Alternative, if there's an other @RequestScope active (as suggested below) it will end up calling a different bean instance than the user may expect.

While it could work, I wonder if this aspect wouldn't be a bit confusing?

Someone over on the JMS user alias told me about this yesterday. So that would avoid the need to call a method to trigger lazy initialisation on normal-scoped bean proxies. I presume the application still has to inject the bean.

If so then it sounds useful. Is it going to be included as a standard feature of CDI 2.0? I see someone has proposed https://issues.jboss.org/browse/CDI-473 .

Nigel