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.
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.
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).
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)?
On 2014-03-05, at 4:37 AM, Martin Kouba <
mkouba@redhat.com>
wrote:
> FYI I've informed CDI EG and it will be
discussed on the next meeting
> whether to clarify this already in CDI 1.2
MR...
>
> M
>
> Dne 5.3.2014 10:19, Jozef Hartinger napsal(a):
>> Agreed. It is definitely not the intention
of the specification to allow
>> beans/observers/contexts to be added at
runtime and applications should
>> not have any expectations of what these
methods do when invoked outside
>> of the AfterBeanDiscovery observer.
>>
>> We'll add stricter validation to Weld to
disallow this.
>>
>> On 03/05/2014 08:53 AM, Martin Kouba wrote:
>>> Hi Christian,this
>>>
>>> actually invoking any container
lifecycle event method after the
>>> container initialization finished
should have no effect. ABD event
>>> reference can escape but it does not
mean you can invoke ABD.addBean()
>>> after ADV is fired.
>>>
>>> The spec wording is not very explicit
here:
>>> "During the application initialization
process, the container fires a
>>> series of events, allowing portable
extensions to integrate with
>>> the container initialization process
defined in Section 12.2."
>>>
>>> Maybe we should file a new spec issue
to clarify that such invocations
>>> should result in
IllegalStateException...
>>>
>>> Martin
>>>
>>>
>>> Dne 4.3.2014 17:42, Christian Sadilek
napsal(a):
>>>> Hi Jozef,
>>>>
>>>> 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.
>>>>
>>>> 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).
>>>>
>>>> Cheers,
>>>> Christian
>>>>
>>>> On 2014-03-04, at 11:29 AM, Jozef
Hartinger <
jharting@redhat.com>
wrote:
>>>>
>>>>> Hi Christian,
>>>>>
>>>>> 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
https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L415)
>>>>>
>>>>> Jozef
>>>>>
>>>>> On 03/04/2014 04:36 PM,
Christian Sadilek wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Possible solutions:
>>>>>>
>>>>>> - 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.
>>>>>>
>>>>>> - Recompute the
corresponding part of the cache when
addObserverMethod is called (seems preferable).
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> What do you think? Can this
already be done or is there another solution?
>>>>>>
>>>>>> Cheers,
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
_______________________________________________
>>>>>> weld-dev mailing list
>>>>>>
weld-dev@lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>>>
_______________________________________________
>>>> weld-dev mailing list
>>>>
weld-dev@lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>
_______________________________________________
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev