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

Reply via email to