<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div><div class="gmail_quote">2015-08-27 17:31 GMT+02:00 Nigel Deakin <span dir="ltr"><<a href="mailto:nigel.deakin@oracle.com" target="_blank">nigel.deakin@oracle.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26/08/2015 10:16, Romain Manni-Bucau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
The sample I gave before with the JmsStart event basically:<br>
<br>
<br>
public class JmsRegistrar {<br>
@Inject<br>
@JmsConnectionFactory(...)<br>
private ConnectionFactory factory;<br>
<br>
@Inject<br>
@JmsQueue(...)<br>
private Queue queue;<br>
<br>
public void startJms(@Observes JmsStart start) {<br>
start.withFactory(factory) // withFactory should be optional if only 1 bean matches it<br>
.register(MyCdiTypedListener.class) // with defaults for all potential config<br>
.listenOn(queue)<br>
.register(MyCdiTypedListener2.class, new MyLiteral())<br>
.withMaxSessions(10)<br>
.listenOn(Queue.class, new QueueLiteral(...))<br>
......;<br>
}<br>
}<br>
<br>
<br>
The power of it appears when you have a config injection in JmsRegistrar you can iterate over to get the list of<br>
listener for instance.<br>
<br>
Also JMS resources can be decorated and referenced from qualifiers instead of instances thanks to CDI.<br>
<br>
It doesnt prevent the app to use @JmxListener somewhere else if the listener doesnt need any input/config to be registered.<br>
<br>
</blockquote>
<br></span>
I'm trying to understand this. Are you suggesting that<br>
<br>
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.<br>
<br>
2. The application defines a class (in this example called JmsRegistrar). This has a method startJms which receives the event.<br>
<br>
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.<br>
<br>
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?<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Yes this is it, few details important for CDI:</div><div><br></div><div>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</div><div>2- JMS can use contextual instances implicitely which is not the case in SE</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Nigel<br>
</font></span></blockquote></div><br></div></div>