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