The question is more is it mandatory since that's not discovered. There are others ways to test it Le 23 mars 2013 13:24, "Arne Limburg" <[email protected]> a écrit :
> 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 > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
