[cdi-dev] Building EJB-like @Asynchronous via interceptor in CD

Werner Keil werner.keil at gmail.com
Sat Jan 17 12:38:29 EST 2015


Sorry, didn't change the topic when simply hitting reply, that's the thread
for it.

Werner


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


More information about the cdi-dev mailing list