Hmm, but do we fire ProcessBean for build-in beans?
I don't know... Am 23.03.13 13:21 schrieb "Mark Struberg" unter <[email protected]>: > > >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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
