<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 03/25/2015 08:55 AM, Romain
      Manni-Bucau wrote:<br>
    </div>
    <blockquote
cite="mid:CACLE=7PUbbfi2OdMqJSX01Bofb-vBXnCzMcFq5dQmoNUC+xjaA@mail.gmail.com"
      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>
    Agreed.<br>
    <blockquote
cite="mid:CACLE=7PUbbfi2OdMqJSX01Bofb-vBXnCzMcFq5dQmoNUC+xjaA@mail.gmail.com"
      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>
    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<br>
    <blockquote
cite="mid:CACLE=7PUbbfi2OdMqJSX01Bofb-vBXnCzMcFq5dQmoNUC+xjaA@mail.gmail.com"
      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 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 moz-do-not-send="true"
                              href="https://twitter.com/rmannibucau"
                              target="_blank">@rmannibucau</a> |  <a
                              moz-do-not-send="true"
                              href="http://rmannibucau.wordpress.com"
                              target="_blank">Blog</a> | <a
                              moz-do-not-send="true"
                              href="https://github.com/rmannibucau"
                              target="_blank">Github</a> | <a
                              moz-do-not-send="true"
                              href="https://www.linkedin.com/in/rmannibucau"
                              target="_blank">LinkedIn</a> | <a
                              moz-do-not-send="true"
                              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">&lt;<a moz-do-not-send="true"
              href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>&gt;</span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
            &gt; Le 24 mars 2015 à 23:16, Mark Struberg &lt;<a
              moz-do-not-send="true" href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>&gt;
            a écrit :<br>
            <span class="">&gt;<br>
              &gt;<br>
              &gt;<br>
              &gt;&gt; Am 24.03.2015 um 20:59 schrieb José Paumard &lt;<a
                moz-do-not-send="true"
                href="mailto:jose.paumard@gmail.com">jose.paumard@gmail.com</a>&gt;:<br>
              &gt;&gt;<br>
              &gt;&gt; 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>
              &gt;<br>
              &gt;<br>
              &gt; 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>
              &gt; 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>
              &gt;<br>
              &gt; Also note that often you cannot even re-compile libs
              which use observers. So you just cannot just add anything.<br>
              &gt;<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 class=""><br>
              <br>
              &gt;<br>
              &gt;&gt; We could add some information in the beans.xml,
              that would affect all the observers of the bean archive.<br>
              &gt;<br>
              &gt; 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 class=""><br>
              &gt; 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 class=""><br>
              &gt; 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 class=""><br>
              <br>
              &gt; - 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 class=""><br>
              &gt;<br>
              &gt; 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 class="HOEnZb"><font color="#888888"><br>
                <br>
                Antoine<br>
              </font></span><br>
            _______________________________________________<br>
            cdi-dev mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
            <a moz-do-not-send="true"
              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
              moz-do-not-send="true"
              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 class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
cdi-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/cdi-dev">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 class="moz-txt-link-freetext" href="http://www.apache.org/licenses/LICENSE-2.0.html">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>
  </body>
</html>