Canceling today's meeting
by Antoine Sabot-Durand
Hi,
I won't be available for the meeting today. Let's continue our reflexion on SE support and async event for next Wednesday.
Antoine Sabot-Durand
11 years, 1 month
[JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread
by José Paumard (JIRA)
José Paumard created CDI-501:
--------------------------------
Summary: Firing and consuming events should take place in the same thread
Key: CDI-501
URL: https://issues.jboss.org/browse/CDI-501
Project: CDI Specification Issues
Issue Type: Clarification
Components: Events
Affects Versions: 1.2.Final
Reporter: José Paumard
An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload.
All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state.
The issue is the following :
- the payload object is not specified, it can then be mutable, non-synchronized etc...
- it is not stated that the firing of the event and the consuming of the payload should occur in the same thread.
So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise.
Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
Re: [cdi-dev] Today's meeting
by Werner Keil
Guys,
Just noticed, I never joined the IRC chat from here in the company (last
time was mostly Christmas in Austria) and both web URLs or ports seem
blocked by our firewall and proxy, so I'm afraid I can't join today either.
If it's a less busy week I try to be at home by then should work there.
+1 for using Java SE 8 where we can btw. Everything that makes CDI 2 less
dependent on other specs that may become optional in future profiles or
won't even be around in a pure SE/desktop environment sounds like a good
idea.
Werner
On Wed, Jan 21, 2015 at 4:25 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: Today's meeting (Antoine Sabot-Durand)
> 2. Re: [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Werner Keil)
> 3. Re: Building EJB-like @Asynchronous via interceptor in CDI
> (Antoine Sabot-Durand)
> 4. Re: [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Antoine Sabot-Durand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 21 Jan 2015 16:04:38 +0100
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: Re: [cdi-dev] Today's meeting
> To: John Ament <john.d.ament(a)gmail.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID: <6CE398B0-3590-4194-99BF-29C6B147148C(a)sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi John,
>
> Good luck. I?ll be happy to talk to you next week.
>
> Antoine
>
>
> > Le 21 janv. 2015 ? 13:40, John D. Ament <john.d.ament(a)gmail.com> a
> ?crit :
> >
> > Hey guys
> >
> > Was hoping to get to today's meeting, luck's not in my favor and I have
> some surgery today :-( Good news is at least the next six weeks no one
> will bother me right before the scheduled meeting so I'll be there.
> >
> > I just updated the CDI SE ticket based on what we talked about last
> week. I can start marking up the doc in google docs this week as well.
> >
> > - John
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/a6d90af2/at...
>
> ------------------------------
>
> Message: 2
> Date: Wed, 21 Jan 2015 16:07:46 +0100
> From: Werner Keil <werner.keil(a)gmail.com>
> Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events
> asynchronously
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAAGawe0qe3KvDk7r4Tb2zB-EhSWeV4oH64Gq7Y=P2Zg9-V=
> xHg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Antoine,
>
> It seems the exact place for that is still to be found, but even if these
> are separate threads in parallel the fact that CDI 2 aims to add support
> for async events means anything other JSRs cannot do or don't want to do
> (see Bill's remark on resources in other JSRs) would fit into CDI 2 as long
> as the resource situation here isn't too critical either of course;-)
>
> That's what I wanted to say.
>
> Werner
>
> On Wed, Jan 21, 2015 at 4:01 PM, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
>
> > Hi Werner,
> >
> >
> > No, it doesn?t cover @Asynchronous or @Async annotation. Discussion about
> > async operation support in CDI 2.0 is another subject.
> >
> >
> > Le 21 janv. 2015 ? 13:52, Werner Keil <werner.keil(a)gmail.com> a ?crit :
> >
> > Antoine/all,
> >
> > Is it safe to assume any recent discussion about an @Asynchronous
> > annotation would be covered there unless e.g. EJB itself needs it to be
> > updated for EE 8?
> >
> > Werner
> >
> > On Wed, Jan 21, 2015 at 1:06 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. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >> (Antoine Sabot-Durand (JIRA))
> >> 2. [JBoss JIRA] (CDI-31) Asynchronous events
> >> (Antoine Sabot-Durand (JIRA))
> >> 3. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >> (Antoine Sabot-Durand (JIRA))
> >> 4. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >> (Antoine Sabot-Durand (JIRA))
> >> 5. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >> (Jos? Paumard (JIRA))
> >> 6. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >> (Jozef Hartinger (JIRA))
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >>
> >> Message: 6
> >> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
> >> From: "Jozef Hartinger (JIRA)" <issues(a)jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
> >> To: cdi-dev(a)lists.jboss.org
> >> Message-ID:
> >> <JIRA.12561330.1421835166000.18078.1421842009269(a)Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >>
> >> [
> >>
> https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy...
> >> ]
> >>
> >> Jozef Hartinger commented on CDI-499:
> >> -------------------------------------
> >>
> >> {quote}For backward compatibility reason the possibility to invoke an
> >> observer asynchronously should be let to the observer{quote}
> >> What exactly are the reasons for this? I can think of one:
> >> - observer method injecting a @RequestScoped (or similar) bean
> >> Are there other arguments for this?
> >>
> >> {quote}3. Observer bound to a transaction phase
> >> these observer will be invoked in the right transaction phase but
> >> asynchronously{quote}
> >> How's that different from Event.fire()?
> >>
> >> > 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.
> >> > So to be notified asynchronously an observer should have
> >> {{asyncSupported}} member to true. otherwise it will be called
> >> synchronously.
> >> > 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 a mix 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)
> >>
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> 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 42
> >> ***************************************
> >>
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/eb5a3559/at...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 21 Jan 2015 16:20:46 +0100
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
> in CDI
> To: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID: <2D5C8B76-F389-4CE3-92F6-E48EFA0BE8D6(a)sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Guys,
>
> Remember that CDI 2.0 will require JDK8. So user will have very powerful
> asynchronous feature out of the box with the CompletableFuture class. So I
> wonder if we should really focus on this @Asynhcronous annotation and it?s
> right JSR ?
> Whatever we decide here, the first point we should work on IMO is
> specifying how contexts will be propagated (or not) during async operations.
>
> Antoine
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/9036a06f/at...
>
> ------------------------------
>
> Message: 4
> Date: Wed, 21 Jan 2015 16:25:44 +0100
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events
> asynchronously
> To: Werner Keil <werner.keil(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <70D7164E-3C68-46A9-9BCC-F737E5385C85(a)sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> My concern is too avoid creating a new EJB spec with CDI 2. Managing async
> operation is now very simple for end user with java 8, so do we have to add
> annotation to support it. I wonder.
>
> Antoine Sabot-Durand
>
> > Le 21 janv. 2015 ? 16:07, Werner Keil <werner.keil(a)gmail.com> a ?crit :
> >
> > Hi Antoine,
> >
> > It seems the exact place for that is still to be found, but even if
> these are separate threads in parallel the fact that CDI 2 aims to add
> support for async events means anything other JSRs cannot do or don't want
> to do (see Bill's remark on resources in other JSRs) would fit into CDI 2
> as long as the resource situation here isn't too critical either of
> course;-)
> >
> > That's what I wanted to say.
> >
> > Werner
> >
> >> On Wed, Jan 21, 2015 at 4:01 PM, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
> >> Hi Werner,
> >>
> >>
> >> No, it doesn?t cover @Asynchronous or @Async annotation. Discussion
> about async operation support in CDI 2.0 is another subject.
> >>
> >>
> >>> Le 21 janv. 2015 ? 13:52, Werner Keil <werner.keil(a)gmail.com> a ?crit
> :
> >>>
> >>> Antoine/all,
> >>>
> >>> Is it safe to assume any recent discussion about an @Asynchronous
> annotation would be covered there unless e.g. EJB itself needs it to be
> updated for EE 8?
> >>>
> >>> Werner
> >>>
> >>>> On Wed, Jan 21, 2015 at 1:06 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. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>> (Antoine Sabot-Durand (JIRA))
> >>>> 2. [JBoss JIRA] (CDI-31) Asynchronous events
> >>>> (Antoine Sabot-Durand (JIRA))
> >>>> 3. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>> (Antoine Sabot-Durand (JIRA))
> >>>> 4. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>> (Antoine Sabot-Durand (JIRA))
> >>>> 5. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>> (Jos? Paumard (JIRA))
> >>>> 6. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>> (Jozef Hartinger (JIRA))
> >>>>
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>
> >>>>
> >>>> Message: 6
> >>>> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
> >>>> From: "Jozef Hartinger (JIRA)" <issues(a)jboss.org>
> >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>> To: cdi-dev(a)lists.jboss.org
> >>>> Message-ID:
> >>>>
> <JIRA.12561330.1421835166000.18078.1421842009269(a)Atlassian.JIRA>
> >>>> Content-Type: text/plain; charset=UTF-8
> >>>>
> >>>>
> >>>> [
> https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy...
> ]
> >>>>
> >>>> Jozef Hartinger commented on CDI-499:
> >>>> -------------------------------------
> >>>>
> >>>> {quote}For backward compatibility reason the possibility to invoke an
> observer asynchronously should be let to the observer{quote}
> >>>> What exactly are the reasons for this? I can think of one:
> >>>> - observer method injecting a @RequestScoped (or similar) bean
> >>>> Are there other arguments for this?
> >>>>
> >>>> {quote}3. Observer bound to a transaction phase
> >>>> these observer will be invoked in the right transaction phase but
> asynchronously{quote}
> >>>> How's that different from Event.fire()?
> >>>>
> >>>> > 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.
> >>>> > So to be notified asynchronously an observer should have
> {{asyncSupported}} member to true. otherwise it will be called
> synchronously.
> >>>> > 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 a mix 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)
> >>>>
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> _______________________________________________
> >>>> 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 42
> >>>> ***************************************
> >>>
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/3ffd155b/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 45
> ***************************************
>
11 years, 1 month
Re: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
by Werner Keil
Antoine/all,
Is it safe to assume any recent discussion about an @Asynchronous
annotation would be covered there unless e.g. EJB itself needs it to be
updated for EE 8?
Werner
On Wed, Jan 21, 2015 at 1:06 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. [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Antoine Sabot-Durand (JIRA))
> 2. [JBoss JIRA] (CDI-31) Asynchronous events
> (Antoine Sabot-Durand (JIRA))
> 3. [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Antoine Sabot-Durand (JIRA))
> 4. [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Antoine Sabot-Durand (JIRA))
> 5. [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Jos? Paumard (JIRA))
> 6. [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Jozef Hartinger (JIRA))
>
>
> ----------------------------------------------------------------------
>
>
> Message: 6
> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
> From: "Jozef Hartinger (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12561330.1421835166000.18078.1421842009269(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy...
> ]
>
> Jozef Hartinger commented on CDI-499:
> -------------------------------------
>
> {quote}For backward compatibility reason the possibility to invoke an
> observer asynchronously should be let to the observer{quote}
> What exactly are the reasons for this? I can think of one:
> - observer method injecting a @RequestScoped (or similar) bean
> Are there other arguments for this?
>
> {quote}3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but
> asynchronously{quote}
> How's that different from Event.fire()?
>
> > 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.
> > So to be notified asynchronously an observer should have
> {{asyncSupported}} member to true. otherwise it will be called
> synchronously.
> > 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 a mix 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)
>
>
> ------------------------------
>
> _______________________________________________
> 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 42
> ***************************************
>
11 years, 1 month
Building EJB-like @Asynchronous via interceptor in CDI
by arjan tijms
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
11 years, 1 month
Today's meeting
by John D. Ament
Hey guys
Was hoping to get to today's meeting, luck's not in my favor and I have
some surgery today :-( Good news is at least the next six weeks no one
will bother me right before the scheduled meeting so I'll be there.
I just updated the CDI SE ticket based on what we talked about last week.
I can start marking up the doc in google docs this week as well.
- John
11 years, 1 month
[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:
------------------------------------------
[~josepaumard]
{quote}
- the signature of the fireAsync is <U extends T> CompletionStage<U> fireAsync(U event);
I think we need to add a 2nd method that takes an Executor as a parameter, for 2 reasons :
- it would stick to the CompletionStage patterns
- in a Java EE world, it would allow one to state that the processing of the event should take place in a ManagedExecutorService, obtained by injection, that the BeanManager might not be aware of.
{quote}
Discussion is open but I really think we should keep the event system as simple as possible. My feeling is: if someone need a specific executor service he'll manage his own asynchronous call. Event shouldn't be more than notification and basic tasks...
> 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.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> 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 a mix 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)
11 years, 1 month
[JBoss JIRA] (CDI-499) Firing events asynchronously
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-499:
-------------------------------------
{quote}How did you handle that in Weld Alpha Jozef Hartinger?{quote}
Delivery to transactional observers has always been asynchronous so no special treatment.
> 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.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> 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 a mix 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)
11 years, 1 month
Re: [cdi-dev] Today's meeting (John D. Ament)
by Werner Keil
Also very busy with 3 parallel tasks here at the moment (the most critical
one heavily related to Java, JNI and some changes in latest builds of both
Java 7 and 8;-) but maybe later today I could join the IRC from the web
interface.
Werner
On Wed, Jan 21, 2015 at 3:37 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. [JBoss JIRA] (CDI-26) Bootstrap API for CDI (John Ament (JIRA))
> 2. [JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata
> injection for EE components (Martin Kouba (JIRA))
> 3. Today's meeting (John D. Ament)
> 4. [JBoss JIRA] (CDI-26) Bootstrap API for CDI (John Ament (JIRA))
> 5. Re: [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Werner Keil)
> 6. [JBoss JIRA] (CDI-499) Firing events asynchronously
> (Antoine Sabot-Durand (JIRA))
>
>
> ----------------------------------------------------------------------
>
>
>
> Message: 3
> Date: Wed, 21 Jan 2015 12:40:12 +0000
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: [cdi-dev] Today's meeting
> To: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAOqetn_Z=
> wG9tffz_j2+OS1aif2sp2nW+68smghppymuEXraaQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hey guys
>
> Was hoping to get to today's meeting, luck's not in my favor and I have
> some surgery today :-( Good news is at least the next six weeks no one
> will bother me right before the scheduled meeting so I'll be there.
>
> I just updated the CDI SE ticket based on what we talked about last week.
> I can start marking up the doc in google docs this week as well.
>
> - John
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/e3cf1428/at...
>
> ------------------------------
>
11 years, 1 month
