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.