[cdi-dev] Some more thoughts on async events

Wed Mar 25 05:55:25 EDT 2015

On 03/25/2015 08:55 AM, Romain Manni-Bucau wrote:
> Hi guys,
>
> thinking to it I think double activation whatever it is would be a 
> failure. As you said Antoine keep the user eyes. Do you want to 
> activate it twice? I udnerstand the concern but really think - 
> whatever technical reason behind - that as a user this is an API failure.
>
Agreed.
> However I wonder if we just didn't overlooked the issue and can't just 
> say that async is not yet used so we can consider fired payloads will 
> be different (let say to be immutable for instance) so there is surely 
> no conflict in most cases (ie observers can be supposed supporting it 
> in all cases). If not we can detect it and fail.
We cannot really detect upfront if a legacy observer is going to fail 
when executed in a thread other than the event-sending one. Mark gave 
examples of the scenarios we cannot detect, e.g:
- legacy observer depends on a state of a CDI context that is not 
propagated to the thread that executes the observer
- legacy observer depends on transactional state
- legacy observer uses a ThreadLocal
>
> Most of the time observer chain was compared to filter chain but 
> actually filter chain is closer to interceptor chain but not observer 
> one. In other words if we want to do something - hopefully we'll not 
> since it would break most of usages IMO - we should validate all 
> interceptors of all observers. Why is it different. Cause interceptors 
> are synchonous wrapping inheriting from a context when observers are 
> by design "unknown" from the sender getting their data from a message. 
> The fact the sender doesn't care about observers (but just their 
> effects on its enclosing method - execution duration) makes this 
> double activation a pain whereever it is.
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog 
> <http://rmannibucau.wordpress.com> | Github 
> <https://github.com/rmannibucau> | LinkedIn 
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber 
> <http://www.tomitribe.com>
>
> 2015-03-25 7:13 GMT+01:00 Antoine Sabot-Durand 
> <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>>:
>
>
>     > Le 24 mars 2015 à 23:16, Mark Struberg <struberg at yahoo.de
>     <mailto:struberg at yahoo.de>> a écrit :
>     >
>     >
>     >
>     >> Am 24.03.2015 um 20:59 schrieb José Paumard
>     <jose.paumard at gmail.com <mailto:jose.paumard at gmail.com>>:
>     >>
>     >> Having to add this opt-in element on all our legacy observers
>     will be very tedious, so we need to come with a better pattern here.
>     >
>     >
>     > I don’t get you. The opt-in is EXACTLY what is needed for legacy
>     observers. Or do you like to change the behaviour of all the 10000
>     observers out there in HUGE projects? This is way too critical to
>     change it implicitly.
>     > I sadly still have seen way too much projects with barely a test
>     coverage. And those projects will likely blow up if we switch all
>     Observers to async by default…
>     >
>     > Also note that often you cannot even re-compile libs which use
>     observers. So you just cannot just add anything.
>     >
>
>     I think we can think about a way to ease the life of the 90 % user
>     that will want to use async event in their project and will find
>     quite boring to activate it at both ends. We could figure
>     something that add to the proposed feature not, a new feature. If
>     a user know that the majority of observers in his project support
>     async, wouldn’t it be nice to have a way to tell it once and
>     deactivate the few that don’t support it ? That’s what I
>     understand from José proposal.
>
>     To make short : have async deactivated by default and having two
>     way to activate it : on each observer or once in the current
>     archive. And when it’s activate for all observer in the archive
>     give a way to deactivate it on observer basis.
>
>
>     >
>     >> We could add some information in the beans.xml, that would
>     affect all the observers of the bean archive.
>     >
>     > NO WAY!
>
>     Mark, we are on a community ML. People are here to make proposal
>     and brainstorm ideas. So please let people express their ideas and
>     give YOUR disagreement in a polite and non-agressive way. Your
>     objection content will probably be more read.
>
>     > This BDA stuff is already considered a.) legacy
>
>     Says who? Where it’s written in the spec that BDA are legacy? All
>     the bean discovery mechanism is based on BDA. The notion won’t go
>     anywhere soon. It should be better defined in the spec since it’s
>     part of basic mechanism. What about alternatives activation by
>     config (no recompilation) and class filtering for bean discovery?
>     Legacy as well?
>     You cannot explain that observers cannot be async by default with
>     the good example of an application having jar (BDA) compiled with
>     different CDI version and when someone start thinking about a
>     solution based on configuration in BDA explain him that it’s legacy.
>
>     > and there was a good reason why @Priority for Alternatives,
>     Interceptors and Decorators got introduced to get rid of it
>
>     Yes because it was limitative to have them activated for only one
>     BDA and don’t have a way to activate them for the whole application.
>
>
>     > - and b.) badly specced (section 5 and 12 have a different
>     definition of BDA).
>
>     Yes, but since when a concept needing clarification has to be
>     declared legacy?
>
>     >
>     > What we really need btw need some new method on the
>     ProcessObserverMethod to switch async on/off.
>
>     And how will you know that your observer is not part of a BDA
>     compiled in CDI 1.x?
>
>
>     The question is: will it be useful to allow user to activate by
>     configuration (beans.xml or config annotation / class)
>     asyncSupported by default for all their observer they design in
>     their CDI 2.0 application? Anybody having the end user interest in
>     mind will try to examine this question and only answer “no” if it
>     brings more complexity for end user.
>
>     Because we’re not writing this spec for us but for end users.
>
>
>     Antoine
>
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>     Note that for all code provided on this list, the provider
>     licenses the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/bc9380b8/attachment-0001.html