Good point. What I tried to sketch out from my example here was mapping a "JMS container listener" (MDB) to a "business" or "user" listener making sense for the business logic of a particular application domain.

Werner

On Wed, Aug 26, 2015 at 12:10 PM, <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 (Nigel Deakin)
2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
EE application to listen for JMS messages (Romain Manni-Bucau)
3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
EE application to listen for JMS messages (arjan tijms)
4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
EE application to listen for JMS messages (Werner Keil)

----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Aug 2015 10:43:40 +0100
From: Nigel Deakin <nigel.deakin@oracle.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: Jozef Hartinger <jharting@redhat.com>, Romain Manni-Bucau
<rmannibucau@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID: <55DD8A4C.7050107@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

> On 25.08.2015 16:05, Romain Manni-Bucau wrote:
>>
>> For this last case a really elegant solution would be to just reuse
>> @Observes to fire the message from the jms "container" listener and
>> propagate it to the "user" listener. This would then allow to decouple
>> the application listener from JMS.

On 25/08/2015 15:26, Jozef Hartinger wrote:
> Agreed. I think we should leverage the existing CDI event/observer functionality instead of introducing a completely new
> delivery mechanism.

Can you please say a bit more about what you have in mind?

Romain suggests using events to invoke the "user" listener from the "JMS container listener".
That's a useful distinction. Just to clarify the terminology:

"user" listener = listener bean provided by the application
"JMS container listener" = JMS consumer provided by the application server or resource adapter

There needs to be one consumer for every listener bean since the two need to have the same lifecycle, and also so we can
implement JMS queue sematics which require that a message from a queue is delivered to one and only one listener.

The transaction needs to be started by the consumer before invoking the listener and ended after the listener returns.
This allows the acknowledgement of the message (which is performed by the consumer) to take place in the same
transaction as is used by the listener's method.

Currently I'm proposing that the "consumer" invokes the "listener" by a simple method call. I suppose instead of simply
invoking the method it could fire a synchronous event, which only the associated listener instance would receive, but
I'm not sure what the benefit of this would be. Since JMS semantics are very different from CDI event semantics I think
there's a danger that this will be confusing, since the user might think they were getting CDI event semantics, but they
were actually getting JMS semantics.

Since this is a bit of a FAQ, it might be useful to explore the differences between the two semantics, but currently
they seem profoundly different to me. That's why my proposals are built on the CDI bean lifecycle model but not the CDI
event observer model.

Nigel

------------------------------

Message: 2
Date: Wed, 26 Aug 2015 11:46:57 +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=7MYErwNimYDz=5C5+xD5MFV-T8M6wjyw9Ax8p59T6Z2ww@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Something I didnt think before but if you can register a method reference
then CDI event system starts to be useless:

xxx.register(myCdiBean::listenOn);

can be something to investigate API wise maybe

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-08-26 11:43 GMT+02:00 Nigel Deakin <nigel.deakin@oracle.com>:

> > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> >>
> >> For this last case a really elegant solution would be to just reuse
> >> @Observes to fire the message from the jms "container" listener and
> >> propagate it to the "user" listener. This would then allow to decouple
> >> the application listener from JMS.
>
> On 25/08/2015 15:26, Jozef Hartinger wrote:
>
>> Agreed. I think we should leverage the existing CDI event/observer
>> functionality instead of introducing a completely new
>> delivery mechanism.
>>
>
> Can you please say a bit more about what you have in mind?
>
> Romain suggests using events to invoke the "user" listener from the "JMS
> container listener".
> That's a useful distinction. Just to clarify the terminology:
>
> "user" listener = listener bean provided by the application
> "JMS container listener" = JMS consumer provided by the application server
> or resource adapter
>
> There needs to be one consumer for every listener bean since the two need
> to have the same lifecycle, and also so we can implement JMS queue sematics
> which require that a message from a queue is delivered to one and only one
> listener.
>
> The transaction needs to be started by the consumer before invoking the
> listener and ended after the listener returns. This allows the
> acknowledgement of the message (which is performed by the consumer) to take
> place in the same transaction as is used by the listener's method.
>
> Currently I'm proposing that the "consumer" invokes the "listener" by a
> simple method call. I suppose instead of simply invoking the method it
> could fire a synchronous event, which only the associated listener instance
> would receive, but I'm not sure what the benefit of this would be. Since
> JMS semantics are very different from CDI event semantics I think there's a
> danger that this will be confusing, since the user might think they were
> getting CDI event semantics, but they were actually getting JMS semantics.
>
> Since this is a bit of a FAQ, it might be useful to explore the
> differences between the two semantics, but currently they seem profoundly
> different to me. That's why my proposals are built on the CDI bean
> lifecycle model but not the CDI event observer model.
>
> Nigel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a1a16971/attachment-0001.html

------------------------------

Message: 3
Date: Wed, 26 Aug 2015 11:51:30 +0200
From: arjan tijms <arjan.tijms@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: Romain Manni-Bucau <rmannibucau@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
<rmannibucau@gmail.com> wrote:
> Agree for provided scope but JMS + short time scopes will not match well in
> practise so i would worry more about not "default" scopes which can miss
> these events.

Short lived scopes like @RequestScoped may not be the best match indeed.

Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
thing, e.g. there's the expectation that only the current thread will
access it. If the JMS provider will asynchronously call a method on
the bean instance from another thread, then this breaks this
assumption.

------------------------------

Message: 4
Date: Wed, 26 Aug 2015 12:10:37 +0200
From: Werner Keil <werner.keil@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: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
<CAAGawe1bxW1oA_s4t0RNPJCf2hQYgRMsPJatB-M8BCy7xuwRoA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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@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: 1
> Date: Tue, 25 Aug 2015 22:53:21 +0200
> From: arjan tijms <arjan.tijms@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:
> <CAE=-AhCnTyS-ZVAfT9k2jDK=
> k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin@oracle.com>
> wrote:
> > On 25/08/2015 12:38, arjan tijms wrote:
> > This looks very interesting. Does this work with any normal scope?
>
> Yes, all normal scopes that are available in standard Java EE support
> this as far as I know.
>
> There's the small caveat that CDI itself doesn't know about this
> automatically for any custom normal scope. That implementation of such
> scope (via a Context) must explicitly throw these events.
>
> For example, this is what Mojarra does for the @FlowScoped implementation:
>
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
>
> Which is fired when the scope starts here:
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
>
> (the exact same code is used for @ViewScoped in Mojarra as well)
>
>
> > then every time a new request starts, this event is fired which causes an
> > instance of the bean to be created for that request?
>
> Yes, that is what this does ;)
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 25 Aug 2015 23:16:27 +0200
> From: arjan tijms <arjan.tijms@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:
> <CAE=-
> AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin@oracle.com>
> wrote:
> > Someone over on the JMS user alias told me about this yesterday. So that
> > would avoid the need to call a method to trigger lazy initialisation on
> > normal-scoped bean proxies. I presume the application still has to inject
> > the bean.
>
> The bean does not necessarily have to be injected at any point.
>
> With @Eager it will be activated and its @PostConstruct method will be
> invoked in case it hadn't been referenced before (which in case of
> @Eager is unlikely, as it instantiates very early, but still
> theoretically possible).
>
> The bean can of course still be injected or otherwise referenced later
> within the same scope, but as mentioned this is not required.
>
> So for example if you have OmniFaces on your classpath and then only
> the following bean in an application:
>
> @Eager
> @ApplicationScoped
> public class MyEagerApplicationScopedBean {
>
> @PostConstruct
> public void init() {
> System.out.println("Application scoped init!");
> }
> }
>
> Then you'll see "Application scoped init!" being printed in your
> server log when you deploy that application. No other code is needed.
>
>
> > If so then it sounds useful. Is it going to be included as a standard
> > feature of CDI 2.0? I see someone has proposed
> > https://issues.jboss.org/browse/CDI-473 .
>
> As the issue already mentions, this is possible with current day CDI
> already. The proposal may arguably make it a little more concise and a
> little less verbose. An eager attribute on the scope looks like a
> quite minimal and elegant solution. Additionally it may make sense for
> some scopes to restrict for which "IDs' it's eagerly instantiated
> (e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for
> @FlowScoped, etc).
>
> A new @Startup seems more like a very specific usage of the eager
> attribute, namely for @ApplicationScoped (or Singleton?) beans.
>
> Kind regards,
> Arjan
>
>
>
>
>
> >
> > Nigel
> >
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 10:11:21 +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: arjan tijms <arjan.tijms@gmail.com>
> Cc: cdi-dev <cdi-dev@lists.jboss.org>
> Message-ID:
> <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=
> SyQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms@gmail.com>:
>
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin@oracle.com>
> > wrote:
> > > On 25/08/2015 12:38, arjan tijms wrote:
> > > This looks very interesting. Does this work with any normal scope?
> >
> > Yes, all normal scopes that are available in standard Java EE support
> > this as far as I know.
> >
> >
> Events are not mandatory for a normal scope - at least was the case in 1.2
> - so JMS can't rely on it for custom normal scopes.
>
>
> > There's the small caveat that CDI itself doesn't know about this
> > automatically for any custom normal scope. That implementation of such
> > scope (via a Context) must explicitly throw these events.
> >
> > For example, this is what Mojarra does for the @FlowScoped
> implementation:
> >
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
> >
> > Which is fired when the scope starts here:
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
> >
> > (the exact same code is used for @ViewScoped in Mojarra as well)
> >
> >
> > > then every time a new request starts, this event is fired which causes
> an
> > > instance of the bean to be created for that request?
> >
> > Yes, that is what this does ;)
> >
> > Kind regards,
> > Arjan Tijms
> > _______________________________________________
> > 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.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c1f05f1c/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 10:07:01 +0100
> From: Nigel Deakin <nigel.deakin@oracle.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: Romain Manni-Bucau <rmannibucau@gmail.com>
> Cc: cdi-dev <cdi-dev@lists.jboss.org>
> Message-ID: <55DD81B5.9040407@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> (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?
>
> Nigel
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 26 Aug 2015 11:07:46 +0200
> From: arjan tijms <arjan.tijms@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: Romain Manni-Bucau <rmannibucau@gmail.com>
> Cc: cdi-dev <cdi-dev@lists.jboss.org>
> Message-ID:
> <CAE=-
> AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> <rmannibucau@gmail.com> wrote:
> >> Yes, all normal scopes that are available in standard Java EE support
> >> this as far as I know.
> >>
> >
> > Events are not mandatory for a normal scope - at least was the case in
> 1.2 -
> > so JMS can't rely on it for custom normal scopes.
>
> Absolutely true, but that was exactly what I said ;)
>
> All Java EE provided scopes throw the events. For CDI, this is
> mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> @ApplicationScoped and @ConversationScoped.
>
> For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> have to double check whether this is actually in the spec for those
> last two and if not see if we can update it for 2.3.
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 26 Aug 2015 11:09:30 +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: arjan tijms <arjan.tijms@gmail.com>
> Cc: cdi-dev <cdi-dev@lists.jboss.org>
> Message-ID:
> <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=
> kL6gyb5jHb7fdA@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms@gmail.com>:
>
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > <rmannibucau@gmail.com> wrote:
> > >> Yes, all normal scopes that are available in standard Java EE support
> > >> this as far as I know.
> > >>
> > >
> > > Events are not mandatory for a normal scope - at least was the case in
> > 1.2 -
> > > so JMS can't rely on it for custom normal scopes.
> >
> > Absolutely true, but that was exactly what I said ;)
> >
> > All Java EE provided scopes throw the events. For CDI, this is
> > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> > @ApplicationScoped and @ConversationScoped.
> >
> > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> > have to double check whether this is actually in the spec for those
> > last two and if not see if we can update it for 2.3.
> >
> >
> Agree for provided scope but JMS + short time scopes will not match well in
> practise so i would worry more about not "default" scopes which can miss
> these events.
>
>
> > Kind regards,
> > Arjan Tijms
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment-0001.html
>
> ------------------------------
>
> 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
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c56ea2e7/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 22
***************************************