[jboss-dev] ejb3 metadata elements

[Brian Stansberry]

Alexey Loubyansky wrote:
> Brian Stansberry wrote:
>> Alexey Loubyansky wrote:
>>> I am at the final steps cleaning jboss_5_0.xsd and the dtd. I would 
>>> like to clarify which elements are NOT needed (ejb2 legacy) in 
>>> jboss_5_0.xsd. Please, review and let me know.
>>>
>>> For example, 'jboss' element (jbossType)
>>> - container-configurations, invoker-proxy-bindings are removed
>>>
>>>
>>> session element
>>> - configuration-name - can't be removed w/o removing cluster-config 
>>> (do we need cluster-config in the xsd?)
>>
>> Yes, it's needed. But looking at the current jboss_5_0.xsd, 
>> cluster-configType is a child element of service-beanType and 
>> session-beanType, which is how this element is correctly used in EJB3. 
>> How does this force use of configuration-name in an EJB3 deployment?
> 
> It's called from
> 
> public ClusterConfigMetaData determineClusterConfig()
> 
> in JBossSessionBeanMetaData, which calls 
> determineContainerConfiguration() which fails (it always returns 
> non-null or fails). This should be done in a different way then.
> 

That ISE determineContainerConfiguration() throws seems appropriate for 
the EJB2 deployment use case though.

Is there anything that's triggering a call to determineClusterConfig() 
during an EJB3 deployment? That method's meant for an EJB2 deployment, 
called by o.j.m.SessionMetaData.getClusterConfigMetaData(). A simple 
search didn't show anything else, except a delegating call by 
JBossSessionPolicyDecorator, which could probably be replaced by an 
UnsupportedOperationException.

Admittedly, if we messed something up and determineClusterConfig() were 
invoked during an EJB3 deployment, the message from the ISE 
determineContainerConfiguration() throws wouldn't be particularly helpful.

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com