You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by David Blevins <da...@visi.com> on 2010/08/04 00:40:22 UTC
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
Re: EJBUtility.fireEvents
Posted by David Blevins <da...@visi.com>.
On Aug 4, 2010, at 2:25 AM, David Blevins wrote:
>
> On Aug 4, 2010, at 12:18 AM, Mark Struberg wrote:
>
>> But maybe I miss something: what do you mean with different meta-data in this
>> context?
>
> For example, something like this:
>
> <ejb-jar>
> <enterprise-beans>
> <session>
> <ejb-name>BeanOne</ejb-name>
> <ejb-class>org.foo.MyEjbClass</ejb-class>
> <session-type>Stateful</session-type>
> <!-- other metadata -->
> </session>
> <session>
> <ejb-name>BeanTwo</ejb-name>
> <ejb-class>org.foo.MyEjbClass</ejb-class>
> <session-type>Stateful</session-type>
> <!-- other metadata -->
> </session>
> </enterprise-beans>
> </ejb-jar>
>
> The two beans share the same bean class, but could be hooked up to different datasources, persistence units, have different env entries or different timer schedules or interceptors, etc. By ejb terms these are two different ejbs.
>
> Currently this fails because the id indirectly enforces that the bean class be unique because the NewBean id is generated only using class information. If maybe it could append to the BaseEjbBean.getId() value that might work -- that would result in two entries for the same class which might not make sense in this context. Might be better to improve EjbUtility and downstream to register it once and not fail a deployment if the same class shows up again in another BaseEjbBean.
>
> Open to thoughts on the right change.
For now I just added a DuplicateDefinitionException and made BeanManagerImpl throw it and EJBUtility.fireEvents catch/ignore it for this one case. Feel free to just change the code if anyone has a different preference -- anything that works is fine with me.
On a side note, the 'deploymentBeans' collection in BeanManagerImpl uses a set, but the objects added do not implement equals or hashcode. So I flipped the 'addPassivationInfo(bean)' and the 'this.deploymentBeans.add(bean)' calls as the hashmap add in this case is more strict and prevents dirty state from being added. The side note is we may want to implement equals and hashcode.
-David
Re: EJBUtility.fireEvents
Posted by David Blevins <da...@visi.com>.
On Aug 4, 2010, at 12:18 AM, Mark Struberg wrote:
> But maybe I miss something: what do you mean with different meta-data in this
> context?
For example, something like this:
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>BeanOne</ejb-name>
<ejb-class>org.foo.MyEjbClass</ejb-class>
<session-type>Stateful</session-type>
<!-- other metadata -->
</session>
<session>
<ejb-name>BeanTwo</ejb-name>
<ejb-class>org.foo.MyEjbClass</ejb-class>
<session-type>Stateful</session-type>
<!-- other metadata -->
</session>
</enterprise-beans>
</ejb-jar>
The two beans share the same bean class, but could be hooked up to different datasources, persistence units, have different env entries or different timer schedules or interceptors, etc. By ejb terms these are two different ejbs.
Currently this fails because the id indirectly enforces that the bean class be unique because the NewBean id is generated only using class information. If maybe it could append to the BaseEjbBean.getId() value that might work -- that would result in two entries for the same class which might not make sense in this context. Might be better to improve EjbUtility and downstream to register it once and not fail a deployment if the same class shows up again in another BaseEjbBean.
Open to thoughts on the right change.
-David
Re: EJBUtility.fireEvents
Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@visi.com>
> To: dev@openwebbeans.apache.org
> 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 <gu...@yahoo.com>
> >> To: dev@openwebbeans.apache.org
> >> 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 <da...@visi.com>
> >> To: dev@openwebbeans.apache.org
> >> 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
> >>
> >>
> >
> >
> >
> >
>
>
Re: EJBUtility.fireEvents
Posted by David Blevins <da...@visi.com>.
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 <gu...@yahoo.com>
>> To: dev@openwebbeans.apache.org
>> 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 <da...@visi.com>
>> To: dev@openwebbeans.apache.org
>> 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
>>
>>
>
>
>
>
Re: EJBUtility.fireEvents
Posted by Mark Struberg <st...@yahoo.de>.
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 <gu...@yahoo.com>
> To: dev@openwebbeans.apache.org
> 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 <da...@visi.com>
> To: dev@openwebbeans.apache.org
> 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
>
>
Re: EJBUtility.fireEvents
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
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 <da...@visi.com>
To: dev@openwebbeans.apache.org
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