<div dir="ltr">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.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2015-03-25 10:55 GMT+01:00 Jozef Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<br>
<div>On 03/25/2015 08:55 AM, Romain
Manni-Bucau wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi guys,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</blockquote></span>
Agreed.<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote></span>
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:<br>
- legacy observer depends on a state of a CDI context that is not
propagated to the thread that executes the observer<br>
- legacy observer depends on transactional state<br>
- legacy observer uses a ThreadLocal<div><div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<span style="font-size:small">Romain
Manni-Bucau</span><br>
<a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">2015-03-25 7:13 GMT+01:00 Antoine
Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Le 24 mars 2015 à 23:16, Mark Struberg <<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>>
a écrit :<br>
<span>><br>
><br>
><br>
>> Am 24.03.2015 um 20:59 schrieb José Paumard <<a href="mailto:jose.paumard@gmail.com" target="_blank">jose.paumard@gmail.com</a>>:<br>
>><br>
>> 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.<br>
><br>
><br>
> 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.<br>
> 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…<br>
><br>
> Also note that often you cannot even re-compile libs
which use observers. So you just cannot just add anything.<br>
><br>
<br>
</span>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.<br>
<br>
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.<br>
<span><br>
<br>
><br>
>> We could add some information in the beans.xml,
that would affect all the observers of the bean archive.<br>
><br>
> NO WAY!<br>
<br>
</span>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.<br>
<span><br>
> This BDA stuff is already considered a.) legacy<br>
<br>
</span>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?<br>
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.<br>
<span><br>
> and there was a good reason why @Priority for
Alternatives, Interceptors and Decorators got introduced
to get rid of it<br>
<br>
</span>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.<br>
<span><br>
<br>
> - and b.) badly specced (section 5 and 12 have a
different definition of BDA).<br>
<br>
</span>Yes, but since when a concept needing clarification
has to be declared legacy?<br>
<span><br>
><br>
> What we really need btw need some new method on the
ProcessObserverMethod to switch async on/off.<br>
<br>
</span>And how will you know that your observer is not part
of a BDA compiled in CDI 1.x?<br>
<br>
<br>
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.<br>
<br>
Because we’re not writing this spec for us but for end
users.<br>
<span><font color="#888888"><br>
<br>
Antoine<br>
</font></span><br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas provided on this list, the provider
waives all patent and other intellectual property rights
inherent in such information.<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
cdi-dev mailing list
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>