openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Calling BeanManager#getBeans within an extension / caching during OWB startup
Date Sat, 23 Mar 2013 09:00:30 GMT
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" <jens.schumann@openknowledge.de> 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 <struberg@yahoo.de>:
>
> >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 <john.d.ament@gmail.com>
> >>To: user@openwebbeans.apache.org
> >>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
> >><jens.schumann@openknowledge.de> 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
> >>>
> >>>
> >>
> >>
> >>
>
>

Mime
View raw message