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]<mailto:[email protected]>>
Antworten an: 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Datum: Samstag, 23. März 2013 10:00
An: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>>
>>To: [email protected]<mailto:[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]<mailto:[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
>>>
>>>
>>
>>
>>

Reply via email to