[cdi-dev] Some more thoughts on async events

[Antoine Sabot-Durand]

> 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
-------------- 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/20150325/93d5946d/attachment-0001.bin