Agreed.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.
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: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.
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.
2015-03-25 7:13 GMT+01:00 Antoine Sabot-Durand <antoine@sabot-durand.net>:
> Le 24 mars 2015 à 23:16, Mark Struberg <struberg@yahoo.de> a écrit :
>
>
>
>> Am 24.03.2015 um 20:59 schrieb José Paumard <jose.paumard@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@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@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.