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(a)lists.jboss.org> wrote:
Send cdi-dev mailing list submissions to
cdi-dev(a)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(a)lists.jboss.org
You can reach the person managing the list at
cdi-dev-owner(a)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(a)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(a)redhat.com>, Romain Manni-Bucau
<rmannibucau(a)gmail.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID: <55DD8A4C.7050107(a)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(a)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(a)oracle.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID:
<CACLE=7MYErwNimYDz=
5C5+xD5MFV-T8M6wjyw9Ax8p59T6Z2ww(a)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(a)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/at...
------------------------------
Message: 3
Date: Wed, 26 Aug 2015 11:51:30 +0200
From: arjan tijms <arjan.tijms(a)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(a)gmail.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID:
<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=
DAyVa3C54+2EtBK7-g(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
<rmannibucau(a)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(a)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(a)lists.jboss.org>
Message-ID:
<
CAAGawe1bxW1oA_s4t0RNPJCf2hQYgRMsPJatB-M8BCy7xuwRoA(a)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(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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(a)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(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-AhCnTyS-ZVAfT9k2jDK=
> k6QHW4ShUab_Vt+e6WmBN76gWg(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin(a)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...
>
> Which is fired when the scope starts here:
>
>
https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
>
> (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(a)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(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-
> AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin(a)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(a)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(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=
> SyQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com>:
>
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin(a)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...
> >
> > Which is fired when the scope starts here:
> >
> >
>
https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
> >
> > (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(a)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/at...
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 10:07:01 +0100
> From: Nigel Deakin <nigel.deakin(a)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(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <55DD81B5.9040407(a)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(a)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(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-
> AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> <rmannibucau(a)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(a)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(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=
> kL6gyb5jHb7fdA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com>:
>
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > <rmannibucau(a)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/at...
>
> ------------------------------
>
> Message: 7
> Date: Wed, 26 Aug 2015 11:16:04 +0200
> From: Romain Manni-Bucau <rmannibucau(a)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(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=
> 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin(a)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/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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/at...
------------------------------
_______________________________________________
cdi-dev mailing list
cdi-dev(a)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
***************************************