[jboss-dev] ejb3 metadata elements

[Alexey Loubyansky]

Brian Stansberry wrote:
> 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.

Ok, I'll just fix the tests: EJB3 will call getClusterConfig() and EJB2 
- determineClusterConfig().

Thanks,
Alexey