[cdi-dev] Some more thoughts on async events

Romain Manni-Bucau rmannibucau at gmail.com
Wed Mar 25 03:55:48 EDT 2015


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 <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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/95800ec3/attachment.html 


More information about the cdi-dev mailing list