[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-27 17:31 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

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


> Nigel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150827/d36d1035/attachment-0001.html