<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-08-27 18:00 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">On 27/08/2015 16:35, Romain Manni-Bucau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2015-08-27 17:31 GMT+02:00 Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com" target="_blank">nigel.deakin@oracle.com</a> <mailto:<a href="mailto:nigel.deakin@oracle.com" target="_blank">nigel.deakin@oracle.com</a>>>:<div><div class="h5"><br>
<br>
On 26/08/2015 10:16, Romain Manni-Bucau wrote:<br>
<br>
<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<br>
registered.<br>
<br>
<br>
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<br>
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<br>
the event.<br>
<br>
3. JmsStart (the event class) has several builder methods. The most important of these is register() which you can<br>
use to specify the class of a listener. The other methods withFactory, register, withMaxSession and listenOn specify<br>
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<br>
automatically at startup. Apart from triggering the initial event, what is CDI doing for you here?<br>
<br>
<br>
Yes this is it, few details important for CDI:<br>
<br>
1- ensure JMS is CDI ready - ie dont use it before the start event, if JMS uses @Initialized(ApplicationScoped) then the<br>
app cant use it for instance, same using extension AfterValidationDeployment etc...so this event is just to ensure we<br>
dont use "JMS CDI" too early<br>
2- JMS can use contextual instances implicitely which is not the case in SE<br>
<br>
otherwise you are right the API is just fluent compared to what is already there - found it nicer to expose but this<br>
point is maybe personal.<br>
</div></div></blockquote>
<br>
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?<br>
<br></blockquote><div><br></div><div>it would do a lookup in CDI context - using the bean manager most probably. It also means to retrieve the JMS components linked (connection factory, Destination?....) it can do a lookup as well and do the wiring if not ambiguous. Very good point about it is it makes default resource optional - and then makes CDI integration more SE friendly and avoids the pain to rely on a default resource you can't suppose anything about excepted it is there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Options are IMO:</div><div><br></div><div>- get actual instance, at this point in CDI lifecycle you can get them injected if you want or create them manually if you desire</div><div>- use a jms qualifier to find them</div><div><br></div><div>Having both makes sense if a jms qualifier is added.</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>
<br>
<br>
</font></span></blockquote></div><br></div></div>