openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <>
Subject Re: Calling BeanManager#getBeans within an extension / caching during OWB startup
Date Sat, 23 Mar 2013 09:09:49 GMT
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).



Von: Romain Manni-Bucau <<>>
Antworten an: "<>" <<>>
Datum: Samstag, 23. März 2013 10:00
An: "<>" <<>>
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" <<>>
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.


Am 23.03.13 06:57 schrieb "Mark Struberg" unter <<>>:

>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).
>> From: John D. Ament <<>>
>>Sent: Friday, March 22, 2013 11:53 PM
>>Subject: Re: Calling BeanManager#getBeans within an extension / caching
>>during OWB startup
>>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).
>>On Fri, Mar 22, 2013 at 6:41 PM, Jens Schumann
>>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
>>>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

View raw message