the @Inject @New MyBean bean; is essentially the same like MyBean bean = new MyBean(); with the difference that CDI still manages the lifecycle (member injection, @PostConstruct, ...)
For the getId() question: the id of a Bean<T> does uniquely identify the Bean<T> and _NOT_ it's instances! But maybe I miss something: what do you mean with different meta-data in this context? LieGrue, strub ----- Original Message ---- > From: David Blevins <[email protected]> > To: [email protected] > Sent: Wed, August 4, 2010 8:55:39 AM > Subject: Re: EJBUtility.fireEvents > > Ok, so this second @New bean is essentially a pojo (i.e. no longer an ejb)? > > So currently the issue is that you could have say 10 EJBs all using the same >class but different meta-data, but the NewBean.getId is generated from the >class info so all 10 beans will have the same NewBean.getId and deployment >will >fail due to duplicate keys (specifically when adding to the >BeanManagerImpl.passivationBeans collection). > > Any preference on how we deal with this. We can either make the ID unique > for >all 10 bean classes or ignore the duplicate exception. Or perhaps a third >approach of refining the process of adding a NewBean for anything of >BaseEjbBean so it can check to see if the class has already been registered. > > Thoughts? > > > -David > > > > On Aug 3, 2010, at 11:02 PM, Mark Struberg wrote: > > > 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 > >> > >> > > > > > > > > > >
