[cdi-dev] Some more thoughts on async events

Wed Mar 25 06:01:36 EDT 2015

sure we can't detect it but since that's new events that's also new
observers (no CDi 1.x uses async observers). If an app reuse the same
payload it will fail but I don't think we should care about this case.
Would significally simplify the life of users + we can't validate it
anyway, even with observers activating the feature. Said otherwise how do
you ensure today a session scope bean relying on a thread local will work
during session invalidation? you don't and nobody complained. Think we
shouldn't make it more complex than 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 10:55 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:

>
> 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>:
>
>>
>> > Le 24 mars 2015 à 23:16, Mark Struberg <struberg at yahoo.de> a écrit :
>> >
>> >
>> >
>> >> Am 24.03.2015 um 20:59 schrieb José Paumard <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
>> 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 listcdi-dev at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/51785ae7/attachment.html 