see https://issues.jboss.org/browse/CDI-274
Jens, Arne: if you think this is too strict and you only like to prevent getBeans() until AfterBeanDiscovery, then please add your use case. But I think your implementation with hooking into ProcessBean, etc is a good way to get that info. LieGrue, strub >________________________________ > From: Romain Manni-Bucau <[email protected]> >To: [email protected] >Sent: Saturday, March 23, 2013 10:16 AM >Subject: Re: Calling BeanManager#getBeans within an extension / caching during >OWB startup > > >With cdi 1.1 coming we should forbig it IMO >Le 23 mars 2013 10:11, "Arne Limburg" <[email protected]> a écrit : > >The current status is definitely wrong: >>In AfterBeanDiscovery Jens' extension looks up a UT bean via getBeans() which >>initializes our cache, that then "knows" that there is no UT and will never >>return a UT-Bean afterwards, even if the extension adds a UT-Bean. >>So either we have to invalidate that cache on addBean(…) or we have to forbid >>calling getBeans(…) until after the AfterBeanDiscovery event is completely >>processed (after that no bean can be added anyway). >> >> >>WDYT? >> >> >>Cheers, >>Arne >> >>Von: Romain Manni-Bucau <[email protected]> >>Antworten an: "[email protected]" <[email protected]> >>Datum: Samstag, 23. März 2013 10:00 >>An: "[email protected]" <[email protected]> >>Betreff: Re: Calling BeanManager#getBeans within an extension / caching >>during OWB startup >> >> >> >>If we "fix" it it will be a regression then. Just change your extension to >>add a ut with a qualifier and delegate or not to a cdi bean, no? >>Le 23 mars 2013 08:34, "Jens Schumann" <[email protected]> a >>écrit : >> >>OK Marc, >>> >>>Looking forward to 1.1;). >>> >>>Nevertheless I think it's quite confusing that addBean does NOT invalidate >>>OWB caches even though direct BeanManager interaction will not be possible >>>in the future. >>> >>>Jens >>> >>>Am 23.03.13 06:57 schrieb "Mark Struberg" unter <[email protected]>: >>> >>>>Hi Jens! >>>> >>>>Yes, this will be fixed in CDI-1.1. >>>> >>>>The reason is that you would most probably introduce an implicit random >>>>generator. getBeans() during extension booting depends on the order of >>>>the class scanning, on the order of the eventing (some container do all >>>>the events after each other, owb takes one scanned AnnotatedType and does >>>>almost all events for that bean in one go). >>>> >>>>LieGrue, >>>>strub >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>________________________________ >>>>> From: John D. Ament <[email protected]> >>>>>To: [email protected] >>>>>Sent: Friday, March 22, 2013 11:53 PM >>>>>Subject: Re: Calling BeanManager#getBeans within an extension / caching >>>>>during OWB startup >>>>> >>>>> >>>>>Jens, >>>>> >>>>> >>>>>For your first bullet, I believe this is reflected in the CDI 1.1 spec >>>>>now (what you can and cannot inject into an extension). >>>>> >>>>> >>>>>John >>>>> >>>>> >>>>> >>>>>On Fri, Mar 22, 2013 at 6:41 PM, Jens Schumann >>>>><[email protected]> wrote: >>>>> >>>>>Hi all! >>>>>> >>>>>> >>>>>>I tried to upgrade an old project from OWB 1.1.3 to 1.1.7 which >>>>>>obviously failed (since I would not send this e-mail otherwise;). It >>>>>>turned out that I had an extension that checks during >>>>>>AfterBeanDiscovery whether a certain bean exists or not. If the bean >>>>>>(UserTransaction) does not exists the extension registers a new bean of >>>>>>this type. >>>>>> >>>>>> >>>>>>With 1.1.3 it worked perfectly, everything above 1.1.4 failed with an >>>>>>missing UserTransaction dependency in the validate phase. My debugger >>>>>>showed a valid UserTransaction bean in my BeanManager instance, however >>>>>>InjectionResolver#checkInjectionPoints could not resolve my dependency. >>>>>>My extension basically did the following: >>>>>> >>>>>> >>>>>> public void addLinkToResource(@Observes AfterBeanDiscovery event, >>>>>>BeanManager bm) { >>>>>> Set<Bean<?>> set = bm.getBeans(UserTransaction.class); >>>>>> if (set.size() == 0) { >>>>>> // register new UserTransaction >>>>>> event.addBean(Š) >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>>From what I understood the above code enforces an empty set of >>>>>>resolvedComponents in InjectionResolver#implResolveByType, since my >>>>>>getBeans() call will register an empty set for the cached >>>>>>UserTransaction BeanCacheKey. Event.addBean() does not update the cache >>>>>>though. >>>>>> >>>>>> >>>>>>While talking to Arne today it seems that >>>>>> * we definitely should prohibit a call to getBeans() within an >>>>>>extension a CDI spec topic I know. I switched to ProcessBean, >>>>>>ProcessProducerMethod, ProcessProducerField for UserTransaction >>>>>>detection and everything works with 1.1.7. >>>>>> * You guys should check wether addBean should clear cached values >>>>>>within OWB in order to avoid the issue above. >>>>>>I you think this is a bug in OWB I can create a JIRA ticket.Jens >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> > >
