Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
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