in other words, we are adding 1.) the original bean 2.) the bean which can be injected with @New (thus the name)
LieGrue, strub ----- Original Message ---- > From: Gurkan Erdogdu <[email protected]> > To: [email protected] > Sent: Wed, August 4, 2010 7:58:47 AM > Subject: Re: EJBUtility.fireEvents > > Spec section; > > 3.12. @New qualified beans > > Important part is : > > ".... > Note that this second bean exists—and may be enabled and available for > injection—even if the first bean is disabled, > defined by Section 5.1.2, “Enabled and disabled beans”, or if the bean class >is > > deployed outside of a bean archive, > defined in Section 12.1, “Bean archives”, and is therefore not discovered >during > > the bean discovery process defined > Chapter 12, Packaging and deployment. The container discovers @New qualified > beans by inspecting injection points > other enabled beans. > .... > " > > > Thanks; > > --Gurkan > > > ________________________________ > From: David Blevins <[email protected]> > To: [email protected] > Sent: Wed, August 4, 2010 1:40:22 AM > Subject: EJBUtility.fireEvents > > Curious on this part of that method: > > manager.addBean(WebBeansUtil.createNewBean(ejbBean)); > > manager.addBean(ejbBean); > > Wondering why we need to essentially add the bean twice. Running into an >issue > > as the NewBean impl uses only class information to construct the unique ID > of > the bean. This basically puts the restriction that you cannot use the same >EJB > > class twice. In EJB-land you can definitely do that. > > What is the NewBean registration for? > > -David > >
