<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Yes, I don't think Errai should depend
      on this behavior as it is not even in the "undefined" category but
      rather in "implicitly not allowed" or "not the intention of the
      spec" category.<br>
      <br>
      Even from the Weld point of view we use two levels of caching and
      while clearing the main one is easy, dealing with the second layer
      would require adding further complexity just to support this
      corner case.<br>
      <br>
      Therefore, I would suggest to use the other approach you proposed
      where you register a general observer method and dispatch to the
      dynamically added observers within there. It is always hard to
      guess performance implications without doing measurements but as
      long as the general observer method implementation is efficient, I
      would not worry about that one additional method invocation much.<br>
      <br>
      Jozef<br>
      <br>
      On 03/06/2014 10:04 AM, Mark Struberg wrote:<br>
    </div>
    <blockquote
      cite="mid:1394096694.99881.YahooMailNeo@web28906.mail.ir2.yahoo.com"
      type="cite">
      <div style="color:#000; background-color:#fff;
        font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial,
        Lucida Grande, sans-serif;font-size:8pt">Hi Christian!<br>
        <br>
        While I find it nice that this works with OWB I also have to
        agree that this is not a guaranteed behaviour by the spec
        intention.<br>
        What you could do in to hack around this issue is to have an
        @Observes@Any&nbsp; Object method which delivers the events with your
        own dynamic rules.<br>
        But be prepared that this might slow down your app a bit.<br>
        <br>
        LieGrue,<br>
        strub<br>
        <div><span><br>
          </span></div>
        <div style="display: block;" class="yahoo_quoted"> <br>
          <br>
          <div style="font-family: HelveticaNeue, Helvetica Neue,
            Helvetica, Arial, Lucida Grande, sans-serif; font-size:
            8pt;">
            <div style="font-family: HelveticaNeue, Helvetica Neue,
              Helvetica, Arial, Lucida Grande, Sans-Serif; font-size:
              12pt;">
              <div dir="ltr"> <font face="Arial" size="2"> On
                  Wednesday, 5 March 2014, 17:04, Christian Sadilek
                  <a class="moz-txt-link-rfc2396E" href="mailto:csadilek@redhat.com">&lt;csadilek@redhat.com&gt;</a> wrote:<br>
                </font> </div>
              <blockquote style="border-left: 2px solid rgb(16, 16,
                255); margin-left: 5px; margin-top: 5px; padding-left:
                5px;">
                <div class="y_msg_container">Hi,<br clear="none">
                  <br clear="none">
                  Yes, I expected this to not be an officially supported
                  use case. So, I guess it's just a matter of improving
                  the API design/documentation.<br clear="none">
                  <br clear="none">
                  However, dynamically registering an observer method
                  would really be useful in the case of Errai where we
                  set up an event bridge between the server and the
                  client and potentially discover new observers at
                  runtime.<br clear="none">
                  <br clear="none">
                  We could work around this by registering an observer
                  method that observes all events and then handle the
                  dispatching internally but that seems less efficient.
                  Right now this works because OpenWebBeans doesn't
                  cache the observers and allows invocations to
                  AfterBeanDiscovery.addObserverMethod at runtime and
                  because Weld has the functionality to clear the
                  observer cache (although that's not public API).<br
                    clear="none">
                  <br clear="none">
                  My questions is: Is there a good reason not to support
                  this going forward? Can we add alternative
                  functionality to add observer methods at runtime (not
                  using ABD)?<br clear="none">
                  <br clear="none">
                  Cheers,<br clear="none">
                  Christian<br clear="none">
                  <div class="yqt8792444993" id="yqtfd69652"><br
                      clear="none">
                    On 2014-03-05, at 4:37 AM, Martin Kouba &lt;<a
                      moz-do-not-send="true" shape="rect"
                      ymailto="mailto:mkouba@redhat.com"
                      href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>&gt;
                    wrote:<br clear="none">
                    <br clear="none">
                    &gt; FYI I've informed CDI EG and it will be
                    discussed on the next meeting<br clear="none">
                    &gt; whether to clarify this already in CDI 1.2
                    MR...<br clear="none">
                    &gt; <br clear="none">
                    &gt; M<br clear="none">
                    &gt; <br clear="none">
                    &gt; Dne 5.3.2014 10:19, Jozef Hartinger napsal(a):<br
                      clear="none">
                    &gt;&gt; Agreed. It is definitely not the intention
                    of the specification to allow <br clear="none">
                    &gt;&gt; beans/observers/contexts to be added at
                    runtime and applications should <br clear="none">
                    &gt;&gt; not have any expectations of what these
                    methods do when invoked outside <br clear="none">
                    &gt;&gt; of the AfterBeanDiscovery observer.<br
                      clear="none">
                    &gt;&gt; <br clear="none">
                    &gt;&gt; We'll add stricter validation to Weld to
                    disallow this.<br clear="none">
                    &gt;&gt; <br clear="none">
                    &gt;&gt; On 03/05/2014 08:53 AM, Martin Kouba wrote:<br
                      clear="none">
                    &gt;&gt;&gt; Hi Christian,this<br clear="none">
                    &gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt; actually invoking any container
                    lifecycle event method after the<br clear="none">
                    &gt;&gt;&gt; container initialization finished
                    should have no effect. ABD event<br clear="none">
                    &gt;&gt;&gt; reference can escape but it does not
                    mean you can invoke ABD.addBean()<br clear="none">
                    &gt;&gt;&gt; after ADV is fired.<br clear="none">
                    &gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt; The spec wording is not very explicit
                    here:<br clear="none">
                    &gt;&gt;&gt; "During the application initialization
                    process, the container fires a<br clear="none">
                    &gt;&gt;&gt; series of events, allowing portable
                    extensions to integrate with<br clear="none">
                    &gt;&gt;&gt; the container initialization process
                    defined in Section 12.2."<br clear="none">
                    &gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt; Maybe we should file a new spec issue
                    to clarify that such invocations<br clear="none">
                    &gt;&gt;&gt; should result in
                    IllegalStateException...<br clear="none">
                    &gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt; Martin<br clear="none">
                    &gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt; Dne 4.3.2014 17:42, Christian Sadilek
                    napsal(a):<br clear="none">
                    &gt;&gt;&gt;&gt; Hi Jozef,<br clear="none">
                    &gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt; I think clearing the cache at the
                    end of the Weld bootstrap process is not enough to
                    solve that particular problem since a CDI extension
                    can hold on to the ABD reference and invoke
                    addObserverMethod later (multiple times) which
                    causes the same problem I described below. There's
                    no indication to the caller of addObserverMethod
                    that it's in fact too late to call that method.<br
                      clear="none">
                    &gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt; Since an ABD event reference can
                    always escape (can be used outside the method that
                    observes it) it seems this issue should be resolved
                    (although it admittedly is an edge case).<br
                      clear="none">
                    &gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt; Cheers,<br clear="none">
                    &gt;&gt;&gt;&gt; Christian<br clear="none">
                    &gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt; On 2014-03-04, at 11:29 AM, Jozef
                    Hartinger &lt;<a moz-do-not-send="true" shape="rect"
                      ymailto="mailto:jharting@redhat.com"
                      href="mailto:jharting@redhat.com">jharting@redhat.com</a>&gt;
                    wrote:<br clear="none">
                    &gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt; Hi Christian,<br clear="none">
                    &gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt; this sounds like a bug. All the
                    resolution caches should be cleared at the very end
                    of Weld's bootstrap sequence (after ABD observers
                    are called). (see <a moz-do-not-send="true"
                      shape="rect"
href="https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L415"
                      target="_blank">https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L415</a>)<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt; Jozef<br clear="none">
                    &gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt; On 03/04/2014 04:36 PM,
                    Christian Sadilek wrote:<br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; Hi everyone,<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; CDI extensions can observe
                    the AfterBeanDiscovery event to register observer
                    methods (addObserverMethod). However, when an event
                    is first fired, the observers for that event are
                    resolved and then cached (in TypeSafeResolver). All
                    future calls to addObserverMethod for an already
                    fired event with corresponding qualifiers will have
                    no effect because the observer result is read from
                    cache and not recomputed.<br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt;&gt; From an API perspective
                    that's unfortunate because addObserverMethod will
                    only work until an event (with corresponding
                    qualifiers) is fired and there is no indication to
                    the caller of that method that it didn't have any
                    effect when invoked after that.<br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; Possible solutions:<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; - Provide some public API
                    to clear/recompute that part the observer cache.
                    Maybe that exists? I couldn't find it which is why I
                    am using the private API and Reflection :(. Also let
                    AfterBeanDiscovery.addObserverMethod fail in that
                    case with the advice to reset the cache.<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; - Recompute the
                    corresponding part of the cache when
                    addObserverMethod is called (seems preferable).<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; OpenWebBeans doesn't have
                    this issue as their NotificationManager will simply
                    add the new ObserverMethod to a ConcurrentHashMap
                    that is also accessed when an event is fired.<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; What do you think? Can this
                    already be done or is there another solution?<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; Cheers,<br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; Christian<br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt;
                    _______________________________________________<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; weld-dev mailing list<br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <a moz-do-not-send="true"
                      shape="rect"
                      ymailto="mailto:weld-dev@lists.jboss.org"
                      href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br
                      clear="none">
                    &gt;&gt;&gt;&gt;&gt;&gt; <a moz-do-not-send="true"
                      shape="rect"
                      href="https://lists.jboss.org/mailman/listinfo/weld-dev"
                      target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br
                      clear="none">
                    &gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt;&gt;&gt;
                    _______________________________________________<br
                      clear="none">
                    &gt;&gt;&gt;&gt; weld-dev mailing list<br
                      clear="none">
                    &gt;&gt;&gt;&gt; <a moz-do-not-send="true"
                      shape="rect"
                      ymailto="mailto:weld-dev@lists.jboss.org"
                      href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br
                      clear="none">
                    &gt;&gt;&gt;&gt; <a moz-do-not-send="true"
                      shape="rect"
                      href="https://lists.jboss.org/mailman/listinfo/weld-dev"
                      target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br
                      clear="none">
                    &gt;&gt;&gt;&gt; <br clear="none">
                    &gt;&gt; <br clear="none">
                    <br clear="none">
                    <br clear="none">
                    _______________________________________________<br
                      clear="none">
                    weld-dev mailing list<br clear="none">
                    <a moz-do-not-send="true" shape="rect"
                      ymailto="mailto:weld-dev@lists.jboss.org"
                      href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br
                      clear="none">
                    <a moz-do-not-send="true" shape="rect"
                      href="https://lists.jboss.org/mailman/listinfo/weld-dev"
                      target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br
                      clear="none">
                  </div>
                  <br>
                  <br>
                </div>
              </blockquote>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
weld-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/weld-dev">https://lists.jboss.org/mailman/listinfo/weld-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>