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