Hi Christian, the problem is that CDI is static by design. Anyway feel free to create a feature request in the spec issue tracker (https://issues.jboss.org/browse/CDI).
Martin Dne 5.3.2014 17:01, Christian Sadilek napsal(a): > Hi, > > 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)? > > Cheers, > Christian > > On 2014-03-05, at 4:37 AM, Martin Kouba <[email protected]> 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 <[email protected]> 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 >>>>>>> [email protected] >>>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>>>> >>>>> _______________________________________________ >>>>> weld-dev mailing list >>>>> [email protected] >>>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>>>> >>> > _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
