<div dir="ltr">... with less code, sorry forgot to mention ;-)<br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px;font-size:13px;border-collapse:collapse"><span lang="EN-US" style="font-family:Calibri">Werner </span></p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Aug 26, 2015 at 12:10 PM, Werner Keil <span dir="ltr"><<a href="mailto:werner.keil@gmail.com" target="_blank">werner.keil@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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<br>only 1 bean matches it<br> .register(BookingListener.class) // with defaults for all<br>potential config<br> .listenOn(queue)<br> .register(BookingListener2.class, new BookingLiteral2())<br> .withMaxSessions(10)<br> .listenOn(Queue.class, new QueueLiteral(...))<br> ......;<br> }<br>}<br></div><div><br></div><div><br></div><div>it could allow to accomplish what I did (loosely based on <a href="http://www.jboss.org/quickstarts/eap/payment-cdi-event/" target="_blank">http://www.jboss.org/quickstarts/eap/payment-cdi-event/</a>) forwarding MDB events to custom CDI ones like that.</div><div><br></div><div><div>Class BookingMDB:</div><div> </div><div> @Inject</div><div> private BookingBean booker;</div><div> </div><div> public void onMessage(Message rcvMessage) {</div><div> BytesMessage msg = null;</div><div> try {</div><div> if (rcvMessage instanceof BytesMessage) {</div><div> msg = (BytesMessage) rcvMessage;</div><div> byte[] output = new byte[5];</div><div> msg.readBytes(output);</div><div> booker.book(output);</div><div> } else {</div><div> LOGGER.warning("Message of wrong type: " + rcvMessage.getClass().getName());</div><div> }</div><div> } catch (JMSException e) {</div><div> throw new RuntimeException(e);</div><div> }</div><div><span style="white-space:pre-wrap"> </span>}</div><div><span style="white-space:pre-wrap"> </span></div><div>Class BookingBean:</div><div><span style="white-space:pre-wrap"> </span></div><div> public void book(byte[] msg) {</div><div> BookingEvent bookingEvent = new BookingEvent();</div><div> if (msg[256] = 42} </div><div> bookingEvent.setType(BookingType.OK);</div><div> } else { </div><div> <some other message data triggering a different booking event></div><div> }</div><div> bookingEvent.setMessage(msg);</div><div> bookingEvent.setDatetime(LocalDateTime.now());</div><div><br></div><div> switch (bookingEvent.getType()) {</div><div> case OK:</div><div> BookingEventProducer.fire(bookingEvent);</div><div> break;</div><div><span style="white-space:pre-wrap"> </span>case [...]</div><div> default:</div><div> LOGGER.severe("invalid booking option");</div><div> break;</div><div> }</div><div> }</div></div><div><br></div><div>You'll get the idea about other types involved from the standard CDI example.<br><div class="gmail_extra">We're dealing with BytesMessage because part of that booking process happens on host servers;-)</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px;font-size:13px;border-collapse:collapse"><span lang="EN-US" style="font-family:Calibri">Werner</span></p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Aug 26, 2015 at 11:16 AM, <span dir="ltr"><<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send cdi-dev mailing list submissions to<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cdi-dev-owner@lists.jboss.org" target="_blank">cdi-dev-owner@lists.jboss.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cdi-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (arjan tijms)<br>
2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (arjan tijms)<br>
3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (Romain Manni-Bucau)<br>
4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (Nigel Deakin)<br>
5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (arjan tijms)<br>
6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (Romain Manni-Bucau)<br>
7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (Romain Manni-Bucau)<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 26 Aug 2015 11:16:04 +0200<br>
From: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>><br>
Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean<br>
in a Java EE application to listen for JMS messages<br>
To: Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com" target="_blank">nigel.deakin@oracle.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CACLE=<a href="mailto:7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com" target="_blank">7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2015-08-26 11:07 GMT+02:00 Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com" target="_blank">nigel.deakin@oracle.com</a>>:<br>
<br>
> (Tidying up the top-posting...)<br>
><br>
> Romain Manni-Bucau:<br>
> > ...I see it really nice to not rely only on annotation - and aligned with<br>
> > most specs - since sometimes you just want to either be able to rely on a<br>
> > loop or a custom config to register your listeners. Annotations are too<br>
> > rigid for such cases.<br>
><br>
> Nigel:<br>
> > Obviously, if users don't want to use CDI (or MDBs, which are also<br>
> > declarative), then they would use the normal JMS API. The existing<br>
> > API to register an async message listener isn't good enough,<br>
> > and we may improve it in JMS 2.1, but that's not something that<br>
> > I'd want to bother the people on cdi-dev with.<br>
><br>
> Romain Manni-Bucau:<br>
> > Integrating it in CDI lifecycle through an event allow CDI users to still<br>
> > use it in the right phase of the container boot so it is still important<br>
> > IMO and avoid all users to have their own custom listener for it -<br>
> > @Initialized(AppScoped.class). Also allow to enrich the API through the<br>
> event<br>
> > itself making things smoother IMO.<br>
><br>
> Nigel:<br>
> > I'm sorry I don't understand you.<br>
> > I thought you were asking about an API which does not use annotation.<br>
><br>
> Romain Manni-Bucau:<br>
> > Both are needed (like websocket spec). Annotation one is nice for fully<br>
> business<br>
> > code and/or simple libs but relying on CDI allows to simplify the wiring<br>
> since you<br>
> > can reuse CDI beans under the hood ie have an implicit connection<br>
> factory if<br>
> > there is a single one etc which is not possible in fully SE context.<br>
><br>
> Can you explain the distinction you're making here? You seem to be<br>
> suggesting two alternatives, using "annotation" and "relying on CDI". What<br>
> would an application which uses CDI but which doesn't use annotation look<br>
> like?<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<br>
only 1 bean matches it<br>
.register(MyCdiTypedListener.class) // with defaults for all<br>
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<br>
you can iterate over to get the list of listener for instance.<br>
<br>
Also JMS resources can be decorated and referenced from qualifiers instead<br>
of instances thanks to CDI.<br>
<br>
It doesnt prevent the app to use @JmxListener somewhere else if the<br>
listener doesnt need any input/config to be registered.<br>
<br>
<br>
> Nigel<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/attachment.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/attachment.html</a><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
End of cdi-dev Digest, Vol 57, Issue 21<br>
***************************************<br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>