<div dir="ltr">Sorry, didn't change the topic when simply hitting reply, that's the thread for it.<div><br></div><div>Werner</div><div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 17 Jan 2015 18:35:02 +0100<br>
From: Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>><br>
Subject: Re: [cdi-dev] cdi-dev Digest, Vol 50, Issue 37<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:CAAGawe3reMLKSR1Ey7AUpdaTc8RPTQ7j2wR6ozacDRXxqzt7QA@mail.gmail.com">CAAGawe3reMLKSR1Ey7AUpdaTc8RPTQ7j2wR6ozacDRXxqzt7QA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
All,<br>
<br>
The Java EE 8 EG (which at least Antonio and myself, but also Antoine and<br>
others representing CDI Spec Lead Red Hat are also EG members) has this<br>
paragraph on CDI:<br>
<br>
We plan to enhance the managed bean model to make ease of use features that<br>
are currently available only to selected components available to all<br>
managed beans via the mechanisms provided by CDI. In particular, we plan to<br>
consider enhancements for declarative security by means of CDI interceptors<br>
and for notifications for timed events by means of the CDI event and<br>
observer mechanism.<br>
<br>
<br>
I understand, it mostly aims at using CDI in other JSRs like 375 (somewhere<br>
along the lines of Agorava or its precursor JSR 357;-)<br>
<br>
If it's a completely new annotation (at least for CDI) would it be totally<br>
wrong to define this by CDI itself?<br>
<br>
Of course it's already in EJB (javax.ejb) and given Java EE 8 plans to<br>
prune some of the EJB Spec, that is most clearly one to be touched in EE 8.<br>
<br>
Unless it's something to be pruned of javax.ejb it won't go away from there<br>
either. javax.enterprise.concurrent is so tiny and (unless using others<br>
already;-) doesn't declare a single annotation of its own so far, so why<br>
bother doing so for this one?<br>
<br>
If it feels wrong in javax.ejb or should work entirely without EJB then<br>
consider some place where CDI already has annotations (not just under its<br>
main packages)<br>
CDI 2 aims at a "Standard/Desktop" variant and another one like<br>
"Full/Enterprise" depending on which of these benefit from such annotation<br>
that may influence where to put it.<br>
<br>
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |<br>
Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory<br>
Board Member, Java Track Chair, DWX '15<br>
<br>
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | #EclipseUOMo<br>
| #DeviceMap<br>
| #DevOps<br>
Skype werner.keil | Google+ <a href="http://gplus.to/wernerkeil" target="_blank">gplus.to/wernerkeil</a><br>
<br>
On Sat, Jan 17, 2015 at 4:58 PM, <<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" 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: Building EJB-like @Asynchronous via interceptor in CDI<br>
> (Antonio Goncalves)<br>
> 2. Re: Building EJB-like @Asynchronous via interceptor in CDI<br>
> (Mark Struberg)<br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Sat, 17 Jan 2015 15:58:06 +0000 (UTC)<br>
> From: Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor<br>
> in CDI<br>
> To: Antonio Goncalves <<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>><br>
> Cc: "<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Message-ID:<br>
> <<br>
> <a href="mailto:1807377505.2717120.1421510286847.JavaMail.yahoo@jws11147.mail.ir2.yahoo.com">1807377505.2717120.1421510286847.JavaMail.yahoo@jws11147.mail.ir2.yahoo.com</a><br>
> ><br>
><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> @Antonio: and where/how to start this context? Boils down to the exactly<br>
> same issue.<br>
><br>
> Also remember that @RequestScoped IS already almost the same as it must be<br>
> there for every EJB invocation, @Asynchronous, @Startup @Singleton<br>
> @PostConstruct methods, JMS invocations, etc, etc<br>
><br>
> LieGrue,<br>
> strub<br>
> On Saturday, 17 January 2015, 16:31, Antonio Goncalves <<br>
> <a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>> wrote:<br>
><br>
><br>
> ><br>
> ><br>
> >@Arjan, remember the email I sent to the EE EG entitled "Status of the<br>
> Java EE 8 specifications". Bill Shannon replied :<br>
> ><br>
> ><br>
> >We agree on the long term vision. This is almost entirely a resource<br>
> issue. In order to do this, we have to stop doing something else, or we<br>
> have to delay the release. Based on the feedback we've gotten from the<br>
> community, the things we've chosen to work on right now are the most<br>
> important. We'd like to do what you suggest below as well, but it's most<br>
> likely going to have to be done later.<br>
> ><br>
> ><br>
> ><br>
> >So I don't know how we could "push" for an MR of the EE Concurrency spec.<br>
> Any idea ? Except harassing Bill to add resources to the EE Concurrency<br>
> spec and taking other resources out somewhere else... I don't know how we<br>
> could do this.<br>
> ><br>
> ><br>
> >@Mark EE Concurreny could also add a @ThreadScoped like the one in Weld<br>
> (but with a EE meaning).<br>
> ><br>
> ><br>
> >Antonio<br>
> ><br>
> ><br>
> ><br>
> ><br>
> >On Sat, Jan 17, 2015 at 1:53 PM, Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> wrote:<br>
> ><br>
> >EE concurrency spec needs an update anyway. It currently doesn't<br>
> explicitly require @RequestScoped beans to be supported on a new Thread.<br>
> That breaks tons of frameworks and makes it barely usable in EE7.<br>
> >><br>
> >>LieGrue,<br>
> >>strub<br>
> >><br>
> >><br>
> >>On Saturday, 17 January 2015, 13:12, arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
> wrote:<br>
> >><br>
> >><br>
> >>><br>
> >>><br>
> >>>Hi,<br>
> >>><br>
> >>><br>
> >>><br>
> >>>On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <<br>
> <a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>> wrote:<br>
> >>><br>
> >>>@arjan Your example is base on ManagedExecutorService from the Java EE<br>
> Concurrency spec. That's one topic we've been wondering about : should the<br>
> @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But<br>
> it looks like the spec might not be updated.<br>
> >>><br>
> >>><br>
> >>>The example I showed here would IMHO best be placed in the Java EE<br>
> Concurrency spec. That would in my opinion be a perfect analogy to<br>
> @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and<br>
> Concurrency, so theoretically it could also be put into a third spec.<br>
> >>><br>
> >>><br>
> >>>Personally I would find it strange to put something in spec A, when it<br>
> may better belong in spec B, just because spec B is not updated. What's<br>
> holding the update of Java EE Concurrency back? If most of the EG members<br>
> would be of the opinion that an @Asynchronous interceptor belongs best in<br>
> Java EE Concurrency, then we can just update that spec, right?<br>
> >>><br>
> >>><br>
> >>>I know that MR releases can be quite fast and agile process wise, while<br>
> still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC<br>
> 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member)<br>
> and I think the setup time was pretty fast. Mid feb 2013 we created the<br>
> JIRA issues, the MR draft was published early march 2013 and the release<br>
> was with EE 7 end may 2013.<br>
> >>><br>
> >>><br>
> >>>If it would just be about putting a few interceptors formally in Java<br>
> EE Concurrency, then why not do such small update for it?<br>
> >>><br>
> >>><br>
> >>>Kind regards,<br>
> >>>Arjan<br>
> >>><br>
> >>><br>
> >>>><br>
> >>>>Antonio<br>
> >>>><br>
> >>>><br>
> >>>>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
> wrote:<br>
> >>>><br>
> >>>>Hi,<br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <<br>
> <a href="mailto:jharting@redhat.com">jharting@redhat.com</a>> wrote:<br>
> >>>>><br>
> >>>>>Hi Arjan,<br>
> >>>>>><br>
> >>>>>>I did some changes recently in Weld interceptors and this usecase<br>
> >> now works smoothly. The code is not part of a release yet. See this<br>
> >> test for a simple implementation of an @Async interceptor (basically<br>
> >> the same as your initial attempt). Note that the chain is repeatable<br>
> >> but at the same time it is not reset after dispatch to a different<br>
> >> thread so you no longer need the ThreadLocal nor any other<br>
> >> workaround.<br>
> >>>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>>That's quite a coincidence, it's indeed rather similar ;)<br>
> >>>>><br>
> >>>>><br>
> >>>>>I wonder how it now works though, as the InvocationContext "ctx" does<br>
> not seem to be made aware that it's been dispatched to a different thread<br>
> from within the code. Does it use an internal thread local to keep state or<br>
> so?<br>
> >>>>><br>
> >>>>><br>
> >>>>>I'll also try to see what this does on OWB. Do you think this is<br>
> something that should work, or just something that Weld happens to support<br>
> regardless of the spec?<br>
> >>>>><br>
> >>>>><br>
> >>>>>Kind regards,<br>
> >>>>>Arjan<br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>>><br>
> <a href="https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java" target="_blank">https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java</a><br>
> >>>>>><br>
> >>>>>>Jozef<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>>On 01/16/2015 06:17 PM, arjan tijms wrote:<br>
> >>>>>><br>
> >>>>>>Hi,<br>
> >>>>>>><br>
> >>>>>>><br>
> >>I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.<br>
> >>>>>>><br>
> >>>>>>>Originally I had defined my interceptor as follows;<br>
> >>>>>>><br>
> >>>>>>>@Interceptor<br>
> >>>>>>>@Asynchronous<br>
> >>>>>>>@Priority(APPLICATION)<br>
> >>>>>>>public class AsynchronousInterceptor implements Serializable {<br>
> >>>>>>><br>
> >>>>>>> private static final long serialVersionUID = 1L;<br>
> >>>>>>><br>
> >>>>>>> @Resource<br>
> >>>>>>> private ManagedExecutorService managedExecutorService;<br>
> >>>>>>><br>
> >>>>>>> @AroundInvoke<br>
> >>>>>>> public Object submitAsync(InvocationContext ctx) throws<br>
> >> Exception {<br>
> >>>>>>> return new<br>
> >> FutureDelegator(managedExecutorService.submit( ()-> {<br>
> >> return ctx.proceed(); } ));<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>>}<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>>With FutureDelegator as follows:<br>
> >>>>>>><br>
> >>>>>>>public class FutureDelegator implements Future<Object> {<br>
> >>>>>>><br>
> >>>>>>> private Future<?> future;<br>
> >>>>>>><br>
> >>>>>>> public FutureDelegator(Future<?> future) {<br>
> >>>>>>> this.future = future;<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>> @Override<br>
> >>>>>>> public Object get() throws InterruptedException,<br>
> >> ExecutionException {<br>
> >>>>>>> AsyncResult<?> asyncResult =<br>
> >> (AsyncResult<?>) future.get();<br>
> >>>>>>> if (asyncResult == null) {<br>
> >>>>>>> return null;<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>> return asyncResult.get();<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>> @Override<br>
> >>>>>>> public Object get(long timeout, TimeUnit unit) throws<br>
> >> InterruptedException, ExecutionException, TimeoutException<br>
> >> {<br>
> >>>>>>> AsyncResult<?> asyncResult =<br>
> >> (AsyncResult<?>) future.get(timeout, unit);<br>
> >>>>>>> if (asyncResult == null) {<br>
> >>>>>>> return null;<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>> return asyncResult.get();<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>> @Override<br>
> >>>>>>> public boolean cancel(boolean mayInterruptIfRunning) {<br>
> >>>>>>> return future.cancel(mayInterruptIfRunning);<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>> @Override<br>
> >>>>>>> public boolean isCancelled() {<br>
> >>>>>>> return future.isCancelled();<br>
> >>>>>>> }<br>
> >>>>>>> @Override<br>
> >>>>>>> public boolean isDone() {<br>
> >>>>>>> return future.isDone();<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>>}<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>>This of course didn't quite work, as the InvocationContext will be<br>
> reset after the @AroundInvoke method returns, and an infinite intercept<br>
> loop results (on Weld).<br>
> >>>>>>><br>
> >>>>>>>I got it to work though on Weld by using a thread local check<br>
> >> to break that loop:<br>
> >>>>>>><br>
> >>>>>>>@Interceptor<br>
> >>>>>>>@Asynchronous<br>
> >>>>>>>@Priority(PLATFORM_BEFORE)<br>
> >>>>>>>public class AsynchronousInterceptor implements Serializable {<br>
> >>>>>>><br>
> >>>>>>> private static final long serialVersionUID = 1L;<br>
> >>>>>>><br>
> >>>>>>> @Resource<br>
> >>>>>>> private ManagedExecutorService managedExecutorService;<br>
> >>>>>>><br>
> >>>>>>> private static final ThreadLocal<Boolean><br>
> >> asyncInvocation = new ThreadLocal<Boolean>();<br>
> >>>>>>><br>
> >>>>>>> @AroundInvoke<br>
> >>>>>>> public synchronized Object submitAsync(InvocationContext<br>
> >> ctx) throws Exception {<br>
> >>>>>>><br>
> >>>>>>> if (TRUE.equals(asyncInvocation.get())) {<br>
> >>>>>>> return ctx.proceed();<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>> return new<br>
> >> FutureDelegator(managedExecutorService.submit( ()-> {<br>
> >>>>>>> try {<br>
> >>>>>>> asyncInvocation.set(TRUE);<br>
> >>>>>>> return ctx.proceed();<br>
> >>>>>>> } finally {<br>
> >>>>>>> asyncInvocation.remove();<br>
> >>>>>>> }<br>
> >>>>>>> }));<br>
> >>>>>>> }<br>
> >>>>>>><br>
> >>>>>>>}<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>>But I've got a feeling this works just by chance and not because<br>
> the workaround is so clever.<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>>What do you guys think, what would be the best way to support this<br>
> with the current CDI version? Or would CDI/Interceptors need something like<br>
> Servlet's async support, where the InvocationContext is put into async mode<br>
> whereafter it "simply" allows an other thread to continue processing on it?<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>>Kind regards,<br>
> >>>>>>>Arjan Tijms<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>>_______________________________________________<br>
> >>cdi-dev mailing list <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" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a> Note that for all code<br>
> provided on this list, the provider licenses the code under the Apache<br>
> License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For<br>
> all other ideas provided on this list, the provider waives all patent and<br>
> other intellectual property rights inherent in such information.<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" 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<br>
> the code under the Apache License, Version 2 (<br>
> <a href="http://www.apache.org/licenses/LICENSE-2.0.html" 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>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>>--<br>
> >>>><br>
> >>>>Antonio Goncalves<br>
> >>>>Software architect, Java Champion and Pluralsight author<br>
> >>>><br>
> >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<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" 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" 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>
> >>><br>
> >><br>
> ><br>
> ><br>
> ><br>
> >--<br>
> ><br>
> >Antonio Goncalves<br>
> >Software architect, Java Champion and Pluralsight author<br>
> ><br>
> >Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<br>
> ><br>
> ><br>
><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" 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" 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 50, Issue 37<br>
> ***************************************<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/52d66852/attachment.html" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/52d66852/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" 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" 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 50, Issue 38<br>
***************************************<br>
</blockquote></div><br></div></div></div>