[cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
Werner Keil
werner.keil at gmail.com
Wed Aug 26 06:12:57 EDT 2015
... with less code, sorry forgot to mention ;-)
Werner
On Wed, Aug 26, 2015 at 12:10 PM, Werner Keil <werner.keil at gmail.com> wrote:
> 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:
>
> @Inject
> private 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 at lists.jboss.org> wrote:
>
>> Send cdi-dev mailing list submissions to
>> cdi-dev at 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 at lists.jboss.org
>>
>> You can reach the person managing the list at
>> cdi-dev-owner at 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 at 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 at oracle.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>> <CACLE=
>> 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin at 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 at 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
>> ***************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/0aaf2877/attachment.html
More information about the cdi-dev
mailing list