<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi guys,<div><br></div><div>Fair enough. This is the outcome I expected. I do think, however, that the docs for ABD need some clarification here and ideally the ABD instance should be "deactivated" once the bootstrap process finished so it can throw an exception when e.g. addObserverMethod is invoked too late in the game (better than silently having no effect).</div><div><br></div><div>Thanks for your answers!</div><div><br></div><div>Cheers,</div><div>Christian<div><br><div><div>On 2014-03-06, at 5:24 AM, Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div 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="background-color: rgb(255, 255, 255); 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 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"><csadilek@redhat.com></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 <<a moz-do-not-send="true" shape="rect" ymailto="mailto:mkouba@redhat.com" href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>>
wrote:<br clear="none">
<br clear="none">
> FYI I've informed CDI EG and it will be
discussed on the next meeting<br clear="none">
> whether to clarify this already in CDI 1.2
MR...<br clear="none">
> <br clear="none">
> M<br clear="none">
> <br clear="none">
> Dne 5.3.2014 10:19, Jozef Hartinger napsal(a):<br clear="none">
>> Agreed. It is definitely not the intention
of the specification to allow <br clear="none">
>> beans/observers/contexts to be added at
runtime and applications should <br clear="none">
>> not have any expectations of what these
methods do when invoked outside <br clear="none">
>> of the AfterBeanDiscovery observer.<br clear="none">
>> <br clear="none">
>> We'll add stricter validation to Weld to
disallow this.<br clear="none">
>> <br clear="none">
>> On 03/05/2014 08:53 AM, Martin Kouba wrote:<br clear="none">
>>> Hi Christian,this<br clear="none">
>>> <br clear="none">
>>> actually invoking any container
lifecycle event method after the<br clear="none">
>>> container initialization finished
should have no effect. ABD event<br clear="none">
>>> reference can escape but it does not
mean you can invoke ABD.addBean()<br clear="none">
>>> after ADV is fired.<br clear="none">
>>> <br clear="none">
>>> The spec wording is not very explicit
here:<br clear="none">
>>> "During the application initialization
process, the container fires a<br clear="none">
>>> series of events, allowing portable
extensions to integrate with<br clear="none">
>>> the container initialization process
defined in Section 12.2."<br clear="none">
>>> <br clear="none">
>>> Maybe we should file a new spec issue
to clarify that such invocations<br clear="none">
>>> should result in
IllegalStateException...<br clear="none">
>>> <br clear="none">
>>> Martin<br clear="none">
>>> <br clear="none">
>>> <br clear="none">
>>> Dne 4.3.2014 17:42, Christian Sadilek
napsal(a):<br clear="none">
>>>> Hi Jozef,<br clear="none">
>>>> <br clear="none">
>>>> 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">
>>>> <br clear="none">
>>>> 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">
>>>> <br clear="none">
>>>> Cheers,<br clear="none">
>>>> Christian<br clear="none">
>>>> <br clear="none">
>>>> On 2014-03-04, at 11:29 AM, Jozef
Hartinger <<a moz-do-not-send="true" shape="rect" ymailto="mailto:jharting@redhat.com" href="mailto:jharting@redhat.com">jharting@redhat.com</a>>
wrote:<br clear="none">
>>>> <br clear="none">
>>>>> Hi Christian,<br clear="none">
>>>>> <br clear="none">
>>>>> 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">
>>>>> <br clear="none">
>>>>> Jozef<br clear="none">
>>>>> <br clear="none">
>>>>> On 03/04/2014 04:36 PM,
Christian Sadilek wrote:<br clear="none">
>>>>>> Hi everyone,<br clear="none">
>>>>>> <br clear="none">
>>>>>> 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">
>>>>>> <br clear="none">
>>>>>>> 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">
>>>>>> <br clear="none">
>>>>>> Possible solutions:<br clear="none">
>>>>>> <br clear="none">
>>>>>> - 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">
>>>>>> <br clear="none">
>>>>>> - Recompute the
corresponding part of the cache when
addObserverMethod is called (seems preferable).<br clear="none">
>>>>>> <br clear="none">
>>>>>> 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">
>>>>>> <br clear="none">
>>>>>> What do you think? Can this
already be done or is there another solution?<br clear="none">
>>>>>> <br clear="none">
>>>>>> Cheers,<br clear="none">
>>>>>> Christian<br clear="none">
>>>>>> <br clear="none">
>>>>>> <br clear="none">
>>>>>> <br clear="none">
>>>>>> <br clear="none">
>>>>>> <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">
>>>> <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">
>>>> <br clear="none">
>> <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>
</div>
</blockquote></div><br></div></div></body></html>