Re: [jboss-dev] ejb3 metadata elements
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(a)redhat.com