<div dir="ltr">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.<div> <div class="gmail_extra"><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, <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">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">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">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 (Nigel Deakin)<br>
2. 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>
3. 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>
4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java<br>
EE application to listen for JMS messages (Werner Keil)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 26 Aug 2015 10:43:40 +0100<br>
From: Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.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: Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>>, Romain Manni-Bucau<br>
<<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID: <<a href="mailto:55DD8A4C.7050107@oracle.com">55DD8A4C.7050107@oracle.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
> On 25.08.2015 16:05, Romain Manni-Bucau wrote:<br>
>><br>
>> For this last case a really elegant solution would be to just reuse<br>
>> @Observes to fire the message from the jms "container" listener and<br>
>> propagate it to the "user" listener. This would then allow to decouple<br>
>> the application listener from JMS.<br>
<br>
On 25/08/2015 15:26, Jozef Hartinger wrote:<br>
> Agreed. I think we should leverage the existing CDI event/observer functionality instead of introducing a completely new<br>
> delivery mechanism.<br>
<br>
Can you please say a bit more about what you have in mind?<br>
<br>
Romain suggests using events to invoke the "user" listener from the "JMS container listener".<br>
That's a useful distinction. Just to clarify the terminology:<br>
<br>
"user" listener = listener bean provided by the application<br>
"JMS container listener" = JMS consumer provided by the application server or resource adapter<br>
<br>
There needs to be one consumer for every listener bean since the two need to have the same lifecycle, and also so we can<br>
implement JMS queue sematics which require that a message from a queue is delivered to one and only one listener.<br>
<br>
The transaction needs to be started by the consumer before invoking the listener and ended after the listener returns.<br>
This allows the acknowledgement of the message (which is performed by the consumer) to take place in the same<br>
transaction as is used by the listener's method.<br>
<br>
Currently I'm proposing that the "consumer" invokes the "listener" by a simple method call. I suppose instead of simply<br>
invoking the method it could fire a synchronous event, which only the associated listener instance would receive, but<br>
I'm not sure what the benefit of this would be. Since JMS semantics are very different from CDI event semantics I think<br>
there's a danger that this will be confusing, since the user might think they were getting CDI event semantics, but they<br>
were actually getting JMS semantics.<br>
<br>
Since this is a bit of a FAQ, it might be useful to explore the differences between the two semantics, but currently<br>
they seem profoundly different to me. That's why my proposals are built on the CDI bean lifecycle model but not the CDI<br>
event observer model.<br>
<br>
Nigel<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 26 Aug 2015 11:46:57 +0200<br>
From: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">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">nigel.deakin@oracle.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CACLE=7MYErwNimYDz=<a href="mailto:5C5%2BxD5MFV-T8M6wjyw9Ax8p59T6Z2ww@mail.gmail.com">5C5+xD5MFV-T8M6wjyw9Ax8p59T6Z2ww@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Something I didnt think before but if you can register a method reference<br>
then CDI event system starts to be useless:<br>
<br>
xxx.register(myCdiBean::listenOn);<br>
<br>
can be something to investigate API wise maybe<br>
<br>
<br>
Romain Manni-Bucau<br>
@rmannibucau <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/rmannibucau</a>> | Blog<br>
<<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.com</a>> | Github <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/rmannibucau</a>> |<br>
LinkedIn <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/rmannibucau</a>> | Tomitriber<br>
<<a href="http://www.tomitribe.com" rel="noreferrer" target="_blank">http://www.tomitribe.com</a>><br>
<br>
2015-08-26 11:43 GMT+02:00 Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>>:<br>
<br>
> > On 25.08.2015 16:05, Romain Manni-Bucau wrote:<br>
> >><br>
> >> For this last case a really elegant solution would be to just reuse<br>
> >> @Observes to fire the message from the jms "container" listener and<br>
> >> propagate it to the "user" listener. This would then allow to decouple<br>
> >> the application listener from JMS.<br>
><br>
> On 25/08/2015 15:26, Jozef Hartinger wrote:<br>
><br>
>> Agreed. I think we should leverage the existing CDI event/observer<br>
>> functionality instead of introducing a completely new<br>
>> delivery mechanism.<br>
>><br>
><br>
> Can you please say a bit more about what you have in mind?<br>
><br>
> Romain suggests using events to invoke the "user" listener from the "JMS<br>
> container listener".<br>
> That's a useful distinction. Just to clarify the terminology:<br>
><br>
> "user" listener = listener bean provided by the application<br>
> "JMS container listener" = JMS consumer provided by the application server<br>
> or resource adapter<br>
><br>
> There needs to be one consumer for every listener bean since the two need<br>
> to have the same lifecycle, and also so we can implement JMS queue sematics<br>
> which require that a message from a queue is delivered to one and only one<br>
> listener.<br>
><br>
> The transaction needs to be started by the consumer before invoking the<br>
> listener and ended after the listener returns. This allows the<br>
> acknowledgement of the message (which is performed by the consumer) to take<br>
> place in the same transaction as is used by the listener's method.<br>
><br>
> Currently I'm proposing that the "consumer" invokes the "listener" by a<br>
> simple method call. I suppose instead of simply invoking the method it<br>
> could fire a synchronous event, which only the associated listener instance<br>
> would receive, but I'm not sure what the benefit of this would be. Since<br>
> JMS semantics are very different from CDI event semantics I think there's a<br>
> danger that this will be confusing, since the user might think they were<br>
> getting CDI event semantics, but they were actually getting JMS semantics.<br>
><br>
> Since this is a bit of a FAQ, it might be useful to explore the<br>
> differences between the two semantics, but currently they seem profoundly<br>
> different to me. That's why my proposals are built on the CDI bean<br>
> lifecycle model but not the CDI event observer model.<br>
><br>
> Nigel<br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a1a16971/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a1a16971/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 26 Aug 2015 11:51:30 +0200<br>
From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@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: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=<a href="mailto:DAyVa3C54%2B2EtBK7-g@mail.gmail.com">DAyVa3C54+2EtBK7-g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau<br>
<<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wrote:<br>
> Agree for provided scope but JMS + short time scopes will not match well in<br>
> practise so i would worry more about not "default" scopes which can miss<br>
> these events.<br>
<br>
Short lived scopes like @RequestScoped may not be the best match indeed.<br>
<br>
Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"<br>
thing, e.g. there's the expectation that only the current thread will<br>
access it. If the JMS provider will asynchronously call a method on<br>
the bean instance from another thread, then this breaks this<br>
assumption.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 26 Aug 2015 12:10:37 +0200<br>
From: Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@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: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<<a href="mailto:CAAGawe1bxW1oA_s4t0RNPJCf2hQYgRMsPJatB-M8BCy7xuwRoA@mail.gmail.com">CAAGawe1bxW1oA_s4t0RNPJCf2hQYgRMsPJatB-M8BCy7xuwRoA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<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(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>
<br>
<br>
it could allow to accomplish what I did (loosely based on<br>
<a href="http://www.jboss.org/quickstarts/eap/payment-cdi-event/" rel="noreferrer" target="_blank">http://www.jboss.org/quickstarts/eap/payment-cdi-event/</a>) forwarding MDB<br>
events to custom CDI ones like that.<br>
<br>
Class BookingMDB:<br>
<br>
@Inject<br>
private BookingBean booker;<br>
<br>
public void onMessage(Message rcvMessage) {<br>
BytesMessage msg = null;<br>
try {<br>
if (rcvMessage instanceof BytesMessage) {<br>
msg = (BytesMessage) rcvMessage;<br>
byte[] output = new byte[5];<br>
msg.readBytes(output);<br>
booker.book(output);<br>
} else {<br>
LOGGER.warning("Message of wrong type: " +<br>
rcvMessage.getClass().getName());<br>
}<br>
} catch (JMSException e) {<br>
throw new RuntimeException(e);<br>
}<br>
}<br>
Class BookingBean:<br>
public void book(byte[] msg) {<br>
BookingEvent bookingEvent = new BookingEvent();<br>
if (msg[256] = 42}<br>
bookingEvent.setType(BookingType.OK);<br>
} else {<br>
<some other message data triggering a different booking event><br>
}<br>
bookingEvent.setMessage(msg);<br>
bookingEvent.setDatetime(LocalDateTime.now());<br>
<br>
switch (bookingEvent.getType()) {<br>
case OK:<br>
BookingEventProducer.fire(bookingEvent);<br>
break;<br>
case [...]<br>
default:<br>
LOGGER.severe("invalid booking option");<br>
break;<br>
}<br>
}<br>
<br>
You'll get the idea about other types involved from the standard CDI<br>
example.<br>
We're dealing with BytesMessage because part of that booking process<br>
happens on host servers;-)<br>
<br>
Werner<br>
<br>
On Wed, Aug 26, 2015 at 11:16 AM, <<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a>> wrote:<br>
<br>
> Send cdi-dev mailing list submissions to<br>
> <a href="mailto:cdi-dev@lists.jboss.org">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">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">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>
><br>
> Message: 1<br>
> Date: Tue, 25 Aug 2015 22:53:21 +0200<br>
> From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@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">nigel.deakin@oracle.com</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID:<br>
> <CAE=-AhCnTyS-ZVAfT9k2jDK=<br>
> <a href="mailto:k6QHW4ShUab_Vt%2Be6WmBN76gWg@mail.gmail.com">k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> Hi,<br>
><br>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><br>
> wrote:<br>
> > On 25/08/2015 12:38, arjan tijms wrote:<br>
> > This looks very interesting. Does this work with any normal scope?<br>
><br>
> Yes, all normal scopes that are available in standard Java EE support<br>
> this as far as I know.<br>
><br>
> There's the small caveat that CDI itself doesn't know about this<br>
> automatically for any custom normal scope. That implementation of such<br>
> scope (via a Context) must explicitly throw these events.<br>
><br>
> For example, this is what Mojarra does for the @FlowScoped implementation:<br>
><br>
><br>
> <a href="https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java" rel="noreferrer" target="_blank">https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java</a><br>
><br>
> Which is fired when the scope starts here:<br>
><br>
> <a href="https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431" rel="noreferrer" target="_blank">https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431</a><br>
><br>
> (the exact same code is used for @ViewScoped in Mojarra as well)<br>
><br>
><br>
> > then every time a new request starts, this event is fired which causes an<br>
> > instance of the bean to be created for that request?<br>
><br>
> Yes, that is what this does ;)<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Tue, 25 Aug 2015 23:16:27 +0200<br>
> From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@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">nigel.deakin@oracle.com</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID:<br>
> <CAE=-<br>
> <a href="mailto:AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2%2BDQ@mail.gmail.com">AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> Hi,<br>
><br>
> On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><br>
> wrote:<br>
> > Someone over on the JMS user alias told me about this yesterday. So that<br>
> > would avoid the need to call a method to trigger lazy initialisation on<br>
> > normal-scoped bean proxies. I presume the application still has to inject<br>
> > the bean.<br>
><br>
> The bean does not necessarily have to be injected at any point.<br>
><br>
> With @Eager it will be activated and its @PostConstruct method will be<br>
> invoked in case it hadn't been referenced before (which in case of<br>
> @Eager is unlikely, as it instantiates very early, but still<br>
> theoretically possible).<br>
><br>
> The bean can of course still be injected or otherwise referenced later<br>
> within the same scope, but as mentioned this is not required.<br>
><br>
> So for example if you have OmniFaces on your classpath and then only<br>
> the following bean in an application:<br>
><br>
> @Eager<br>
> @ApplicationScoped<br>
> public class MyEagerApplicationScopedBean {<br>
><br>
> @PostConstruct<br>
> public void init() {<br>
> System.out.println("Application scoped init!");<br>
> }<br>
> }<br>
><br>
> Then you'll see "Application scoped init!" being printed in your<br>
> server log when you deploy that application. No other code is needed.<br>
><br>
><br>
> > If so then it sounds useful. Is it going to be included as a standard<br>
> > feature of CDI 2.0? I see someone has proposed<br>
> > <a href="https://issues.jboss.org/browse/CDI-473" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-473</a> .<br>
><br>
> As the issue already mentions, this is possible with current day CDI<br>
> already. The proposal may arguably make it a little more concise and a<br>
> little less verbose. An eager attribute on the scope looks like a<br>
> quite minimal and elegant solution. Additionally it may make sense for<br>
> some scopes to restrict for which "IDs' it's eagerly instantiated<br>
> (e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for<br>
> @FlowScoped, etc).<br>
><br>
> A new @Startup seems more like a very specific usage of the eager<br>
> attribute, namely for @ApplicationScoped (or Singleton?) beans.<br>
><br>
> Kind regards,<br>
> Arjan<br>
><br>
><br>
><br>
><br>
><br>
> ><br>
> > Nigel<br>
> ><br>
> ><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 3<br>
> Date: Wed, 26 Aug 2015 10:11:21 +0200<br>
> From: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">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: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID:<br>
> <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=<br>
> <a href="mailto:SyQ@mail.gmail.com">SyQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> 2015-08-25 22:53 GMT+02:00 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>:<br>
><br>
> > Hi,<br>
> ><br>
> > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>><br>
> > wrote:<br>
> > > On 25/08/2015 12:38, arjan tijms wrote:<br>
> > > This looks very interesting. Does this work with any normal scope?<br>
> ><br>
> > Yes, all normal scopes that are available in standard Java EE support<br>
> > this as far as I know.<br>
> ><br>
> ><br>
> Events are not mandatory for a normal scope - at least was the case in 1.2<br>
> - so JMS can't rely on it for custom normal scopes.<br>
><br>
><br>
> > There's the small caveat that CDI itself doesn't know about this<br>
> > automatically for any custom normal scope. That implementation of such<br>
> > scope (via a Context) must explicitly throw these events.<br>
> ><br>
> > For example, this is what Mojarra does for the @FlowScoped<br>
> implementation:<br>
> ><br>
> ><br>
> ><br>
> <a href="https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java" rel="noreferrer" target="_blank">https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java</a><br>
> ><br>
> > Which is fired when the scope starts here:<br>
> ><br>
> ><br>
> <a href="https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431" rel="noreferrer" target="_blank">https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431</a><br>
> ><br>
> > (the exact same code is used for @ViewScoped in Mojarra as well)<br>
> ><br>
> ><br>
> > > then every time a new request starts, this event is fired which causes<br>
> an<br>
> > > instance of the bean to be created for that request?<br>
> ><br>
> > Yes, that is what this does ;)<br>
> ><br>
> > Kind regards,<br>
> > Arjan Tijms<br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org">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<br>
> > code under the Apache License, Version 2 (<br>
> > <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<br>
> > provided on this list, the provider waives all patent and other<br>
> > intellectual property rights inherent in such information.<br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL:<br>
> <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c1f05f1c/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c1f05f1c/attachment-0001.html</a><br>
><br>
> ------------------------------<br>
><br>
> Message: 4<br>
> Date: Wed, 26 Aug 2015 10:07:01 +0100<br>
> From: Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.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: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID: <<a href="mailto:55DD81B5.9040407@oracle.com">55DD81B5.9040407@oracle.com</a>><br>
> Content-Type: text/plain; charset=utf-8; format=flowed<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<br>
> with<br>
> > most specs - since sometimes you just want to either be able to rely on<br>
> 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<br>
> 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<br>
> wiring 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<br>
> "relying on CDI". What would an application which uses CDI but which<br>
> doesn't use annotation look like?<br>
><br>
> Nigel<br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 5<br>
> Date: Wed, 26 Aug 2015 11:07:46 +0200<br>
> From: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@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: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID:<br>
> <CAE=-<br>
> <a href="mailto:AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com">AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> Hi,<br>
><br>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau<br>
> <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wrote:<br>
> >> Yes, all normal scopes that are available in standard Java EE support<br>
> >> this as far as I know.<br>
> >><br>
> ><br>
> > Events are not mandatory for a normal scope - at least was the case in<br>
> 1.2 -<br>
> > so JMS can't rely on it for custom normal scopes.<br>
><br>
> Absolutely true, but that was exactly what I said ;)<br>
><br>
> All Java EE provided scopes throw the events. For CDI, this is<br>
> mandated by the spec (6.7) for @RequestScoped, @SessionScoped,<br>
> @ApplicationScoped and @ConversationScoped.<br>
><br>
> For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I<br>
> have to double check whether this is actually in the spec for those<br>
> last two and if not see if we can update it for 2.3.<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 6<br>
> Date: Wed, 26 Aug 2015 11:09:30 +0200<br>
> From: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">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: arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID:<br>
> <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=<br>
> <a href="mailto:kL6gyb5jHb7fdA@mail.gmail.com">kL6gyb5jHb7fdA@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> 2015-08-26 11:07 GMT+02:00 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>:<br>
><br>
> > Hi,<br>
> ><br>
> > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau<br>
> > <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wrote:<br>
> > >> Yes, all normal scopes that are available in standard Java EE support<br>
> > >> this as far as I know.<br>
> > >><br>
> > ><br>
> > > Events are not mandatory for a normal scope - at least was the case in<br>
> > 1.2 -<br>
> > > so JMS can't rely on it for custom normal scopes.<br>
> ><br>
> > Absolutely true, but that was exactly what I said ;)<br>
> ><br>
> > All Java EE provided scopes throw the events. For CDI, this is<br>
> > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,<br>
> > @ApplicationScoped and @ConversationScoped.<br>
> ><br>
> > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I<br>
> > have to double check whether this is actually in the spec for those<br>
> > last two and if not see if we can update it for 2.3.<br>
> ><br>
> ><br>
> Agree for provided scope but JMS + short time scopes will not match well in<br>
> practise so i would worry more about not "default" scopes which can miss<br>
> these events.<br>
><br>
><br>
> > Kind regards,<br>
> > Arjan Tijms<br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL:<br>
> <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment-0001.html</a><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">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">nigel.deakin@oracle.com</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID:<br>
> <CACLE=<br>
> <a href="mailto:7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com">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">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<br>
> with<br>
> > > most specs - since sometimes you just want to either be able to rely<br>
> 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<br>
> still<br>
> > > use it in the right phase of the container boot so it is still<br>
> 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<br>
> 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".<br>
> 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:<br>
> <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">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<br>
> code under the Apache License, Version 2 (<br>
> <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<br>
> provided on this list, the provider waives all patent and other<br>
> intellectual property rights inherent in such information.<br>
><br>
> End of cdi-dev Digest, Vol 57, Issue 21<br>
> ***************************************<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c56ea2e7/attachment.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c56ea2e7/attachment.html</a><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">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 22<br>
***************************************<br>
</blockquote></div><br></div></div></div>