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
