So if I get it right the issue is for now in CDI you don't really know if the backing instance - if exists - is created or not (ie toString() is not enough). I think on this point CDI can be enhanced to have a isInstantiated() method in its SPI and potentially a forceInstantiation() one to solve it - would also allow to fix the @Startup issue.

Now for JMS having an event based SPI would be a good addition allowing some programmatic registration - naming is to completely to rework but the idea would be:

public void startJms(@Observes final JmsAfterStart jmsStart) {
    jmsStart.registerListener(message -> System.out.println(message))
                 .registerListener(new MyTypedMessageListener()); // or even an injected instance

// JmsBeforeShutdown would be needed as well with a unregister for symmetry but auto deregistration is possible as well

with MyTypedMessageListener:

public class MyTypedMessageListener {
      public void onMessage(MyTypedMessageICreatedInMyApp msg() {}

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


cdi-dev mailing list

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.