[JBoss JIRA] (CDI-499) Firing events asynchronously
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-499:
------------------------------------------
This ticket comes after a lot of discussion around async events in CDI-31 or in the event workshop document. In these discussions there were a lot of more complicated scenario but we wanted to keep CDI event as simple as possible. For advanced asynchronous scenario, JDK8 will provide its new API {{CompletableFuture}} or we could add the support of asynchronous operation in CDI if necessary.
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (CDI-499) Firing events asynchronously
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-499:
-------------------------------------
Description:
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is:
h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}
Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}
h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously
h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
h2. 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
was:
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is:
h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}
Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}
h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously
h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
h2 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (CDI-499) Firing events asynchronously
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-499:
----------------------------------------
Summary: Firing events asynchronously
Key: CDI-499
URL: https://issues.jboss.org/browse/CDI-499
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Events
Affects Versions: 1.2.Final
Reporter: Antoine Sabot-Durand
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is:
h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}
Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}
h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously
h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
h2 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CD
by Werner Keil
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(a)gmail.com>
> Subject: Re: [cdi-dev] cdi-dev Digest, Vol 50, Issue 37
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAAGawe3reMLKSR1Ey7AUpdaTc8RPTQ7j2wR6ozacDRXxqzt7QA(a)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(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: 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(a)yahoo.de>
> > Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
> > in CDI
> > To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> > Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <
> >
> 1807377505.2717120.1421510286847.JavaMail.yahoo(a)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(a)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(a)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(a)gmail.com>
> > wrote:
> > >>
> > >>
> > >>>
> > >>>
> > >>>Hi,
> > >>>
> > >>>
> > >>>
> > >>>On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> > antonio.goncalves(a)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(a)gmail.com
> >
> > wrote:
> > >>>>
> > >>>>Hi,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <
> > jharting(a)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/o...
> > >>>>>>
> > >>>>>>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(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.
> > >>>>>>
> > >>>>>
> > >>>>>_______________________________________________
> > >>>>>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.
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>--
> > >>>>
> > >>>>Antonio Goncalves
> > >>>>Software architect, Java Champion and Pluralsight author
> > >>>>
> > >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> France
> > >>>
> > >>>
> > >>>
> > >>>_______________________________________________
> > >>>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.
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > >--
> > >
> > >Antonio Goncalves
> > >Software architect, Java Champion and Pluralsight author
> > >
> > >Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > >
> > >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > 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 50, Issue 37
> > ***************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/52d66852/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 50, Issue 38
> ***************************************
>
9 years, 9 months
Re: [cdi-dev] cdi-dev Digest, Vol 50, Issue 37
by Werner Keil
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(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: 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(a)yahoo.de>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
> in CDI
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> 1807377505.2717120.1421510286847.JavaMail.yahoo(a)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(a)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(a)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(a)gmail.com>
> wrote:
> >>
> >>
> >>>
> >>>
> >>>Hi,
> >>>
> >>>
> >>>
> >>>On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> antonio.goncalves(a)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(a)gmail.com>
> wrote:
> >>>>
> >>>>Hi,
> >>>>>
> >>>>>
> >>>>>
> >>>>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <
> jharting(a)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/o...
> >>>>>>
> >>>>>>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(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.
> >>>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>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.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>--
> >>>>
> >>>>Antonio Goncalves
> >>>>Software architect, Java Champion and Pluralsight author
> >>>>
> >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>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.
> >>>
> >>>
> >>
> >
> >
> >
> >--
> >
> >Antonio Goncalves
> >Software architect, Java Champion and Pluralsight author
> >
> >Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
>
>
> ------------------------------
>
> _______________________________________________
> 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 50, Issue 37
> ***************************************
>
9 years, 9 months
Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
by Werner Keil
+1
I know JMS 2.x is just about to publish its first change via Errata/MR long
before the actual JSR for 2.1 is going to improve it further towards EE 8.
So it should not be a problem for Concurrency Utility JSR to do the same.
Werner
On Sat, Jan 17, 2015 at 1:53 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: Building EJB-like @Asynchronous via interceptor in CDI
> (arjan tijms)
> 2. Re: Building EJB-like @Asynchronous via interceptor in CDI
> (Mark Struberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 17 Jan 2015 13:11:11 +0100
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
> in CDI
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-
> AhAwfy35WkSD5JQPVRNSQtP1nLuHQ9-U8Mt15AjrJ_qnww(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> antonio.goncalves(a)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(a)gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting(a)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/o...
> >>>
> >>> 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 listcdi-dev@lists.jboss.orghttps://
> 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(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.
> >>
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site <http://www.antoniogoncalves.org> | Twitter
> > <http://twitter.com/agoncal> | LinkedIn
> > <http://www.linkedin.com/in/agoncal> | Pluralsight
> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/0b8212d3/at...
>
> ------------------------------
>
> Message: 2
> Date: Sat, 17 Jan 2015 12:53:04 +0000 (UTC)
> From: Mark Struberg <struberg(a)yahoo.de>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
> in CDI
> To: arjan tijms <arjan.tijms(a)gmail.com>, Antonio Goncalves
> <antonio.goncalves(a)gmail.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> 1515863897.2700554.1421499184135.JavaMail.yahoo(a)jws11122.mail.ir2.yahoo.com
> >
>
> Content-Type: text/plain; charset=UTF-8
>
> 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(a)gmail.com>
> wrote:
>
>
> >
> >
> >Hi,
> >
> >
> >
> >On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> antonio.goncalves(a)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(a)gmail.com>
> wrote:
> >>
> >>Hi,
> >>>
> >>>
> >>>
> >>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting(a)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/o...
> >>>>
> >>>>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(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.
> >>>>
> >>>
> >>>_______________________________________________
> >>>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.
> >>>
> >>
> >>
> >>
> >>--
> >>
> >>Antonio Goncalves
> >>Software architect, Java Champion and Pluralsight author
> >>
> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> >_______________________________________________
> >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.
> >
> >
>
>
> ------------------------------
>
> _______________________________________________
> 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 50, Issue 35
> ***************************************
>
9 years, 9 months
Fw: Answer from EL spec lead: no, "." is not valid in an EL name.
by Mark Struberg
Dear CDI fellows!
I've received an answer regarding our EL question from the EL Spec Lead.
Ed, thanks for helping us!
LieGrue,
strub
> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns(a)oracle.com> wrote:
> > Hello Mark,
>
> To close this out, no, "." is not valid in an EL name. An EL name
> must
> be a java identifier. I'm told this was discussed by Pete a long time
> ago in the EL 3.0 EG.
>
> Ed
>
> --
> | edward.burns(a)oracle.com | office: +1 407 458 0017
> | 42 days til DevNexus 2015
> | 52 days til JavaLand 2015
> | 62 days til CONFESS 2015
>
9 years, 9 months
[JBoss JIRA] (CDI-496) Clarification (or completion) for interceptor binding to session bean
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-496:
----------------------------------------
excepted the CDI container doesnt have to know the EJB actual impl type so how can it validate it? I think it should be done in EJB container - anyway it should be done in EJB container anyway and lifecycle between EJB and CDI container doesnt say today which one would fail first
> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
> Key: CDI-496
> URL: https://issues.jboss.org/browse/CDI-496
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.2.Final
> Reporter: Tomas Remes
> Fix For: 2.0 (discussion)
>
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, “Unproxyable bean types”.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
