So what does unification mean for the ejb conta...| JBoss.org Content Archive (Read Only)

15. Re: So what does unification mean for the ejb containers

starksm64 Oct 15, 2007 1:40 PM (in response to starksm64)

The schemas/dtds need to be in the jar for classpath resource resolution. They were previously in the jboss.jar.

16. Re: So what does unification mean for the ejb containers

starksm64 Oct 15, 2007 3:17 PM (in response to starksm64)

With the schema validation turned on, parsing jboss5.xml docs is failing because of the attribute use restriction:

org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/home/svn/JBossHead/projects/metadata/trunk/target/eclipse-classes/org/jboss/test/metadata/ejb/JBoss5xEverything_testStandard.xml@9,22
...
Caused by: org.xml.sax.SAXException: cvc-complex-type.3.1: Value '5.0' of attribute 'version' of element 'jboss' is not valid with respect to the corresponding attribute use. Attribute 'version' has a fixed value of '3.0'. @ file:/home/svn/JBossHead/projects/metadata/trunk/target/eclipse-classes/org/jboss/test/metadata/ejb/JBoss5xEverything_testStandard.xml[9,22]
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$MetaDataErrorHandler.error(SaxJBossXBParser.java:427)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
...

Both the online and jboss-metadata jboss_5_0.xsd have a fixed value for the version:

 <xsd:attribute name="version" type="javaee:dewey-versionType" fixed="3.0" use="required">
 <xsd:annotation>
 <xsd:documentation> The version specifies the version of the EJB specification that the
 instance document must comply with. This information enables deployment tools to validate
 a particular EJB Deployment Descriptor with respect to a specific version of the EJB
 schema. </xsd:documentation>
 </xsd:annotation>
 </xsd:attribute>

I don't see the reason for restricting this? A jboss5 jboss.xml doc should be applicable to anything from jbossas5.0 - jbossas3.0.

17. Re: So what does unification mean for the ejb containers

starksm64 Oct 15, 2007 3:28 PM (in response to starksm64)

The jboss_5_0.xsd also does not accept the standardjboss.xml elements like invoker-proxy-bindings and container-configurations. These should really exists in some form. For ejb3 they would be referring to aop stacks.

18. Re: So what does unification mean for the ejb containers

wolfc Oct 16, 2007 3:34 AM (in response to starksm64)

If we're going to use the jboss_5_0.xsd for multiple EJB versions, then we must redo the restriction. I don't know the origin of the restriction itself, I would rather restrict it to 5.0 (the product version).

19. Re: So what does unification mean for the ejb containers

wolfc Oct 16, 2007 3:36 AM (in response to starksm64)

Why isn't EnterpriseBeanMetaData.getTransactionType()'s return type javax.ejb.TransactionManagementType?

20. Re: So what does unification mean for the ejb containers

wolfc Oct 16, 2007 3:58 AM (in response to starksm64)

What is considered to be valid state when there is no ejb-jar.xml?
My assumption is that the annotation scanning deployer should have build up an EjbJarMetaData, so in real life we don't encounter this problem?

java.lang.IllegalStateException: ejb-jar.xml has no enterprise beans but jboss.xml has [MyStatelessBean]
 at org.jboss.metadata.javaee.support.JavaEEMetaDataUtil.mergeOverride(JavaEEMetaDataUtil.java:182)
 at org.jboss.metadata.javaee.support.JavaEEMetaDataUtil.mergeOverrideJBossXml(JavaEEMetaDataUtil.java:137)
 at org.jboss.metadata.ejb.jboss.JBossEnterpriseBeansMetaData.merge(JBossEnterpriseBeansMetaData.java:66)
 at org.jboss.metadata.ejb.jboss.JBossMetaData.getMergedEnterpriseBeans(JBossMetaData.java:330)
 at org.jboss.test.metadata.ejb.JBoss50UnitTestCase.testEjbthree936(JBoss50UnitTestCase.java:84)

21. Re: So what does unification mean for the ejb containers

starksm64 Oct 16, 2007 4:00 AM (in response to starksm64)

"wolfc" wrote:
Why isn't EnterpriseBeanMetaData.getTransactionType()'s return type javax.ejb.TransactionManagementType?

Just because the jboss-metadata project does not import this type by depending on the jboss-javaee.jar. It should as there will be other annotations we need.

22. Re: So what does unification mean for the ejb containers

starksm64 Oct 16, 2007 4:03 AM (in response to starksm64)

"wolfc" wrote:
What is considered to be valid state when there is no ejb-jar.xml?
My assumption is that the annotation scanning deployer should have build up an EjbJarMetaData, so in real life we don't encounter this problem?

The jboss.xml parsing deployer just creates an empty EjbJarMetaData if there is not one to use as the JBossMetaData overriden value, so that is what the test should do as well.

23. Re: So what does unification mean for the ejb containers

wolfc Oct 17, 2007 10:14 AM (in response to starksm64)

I can't make the jboss_5_0.xsd, namespace restrictions and model fit together. The spec xsds don't expose any elements, so the only way to use an element in another namespace is by using a ref on a group or by extension. This leads to very weird constructs:

<?xml version="1.0"?>
<jboss
 xmlns="http://www.jboss.com/xml/ns/javaee"
 xmlns:jee="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee
 http://www.jboss.org/j2ee/schema/jboss_5_0.xsd"
 version="3.0">
 <enterprise-beans>
 <service>
 <ejb-name>ServiceSix</ejb-name>
 <ejb-class>org.jboss.ejb3.test.service.ServiceSix</ejb-class>
 <object-name>object name</object-name>
 <local>org.jboss.ejb3.test.service.ServiceSixLocal</local>
 <remote>org.jboss.ejb3.test.service.ServiceSixRemote</remote>
 <management>org.jboss.ejb3.test.service.ServiceSixManagement</management>
 <xmbean>xmbean</xmbean>
 <remote-binding>
 <client-bind-url>client bind url</client-bind-url>
 </remote-binding>
 <jndi-name>serviceSix/remote</jndi-name>
 <local-jndi-name>serviceSix/local</local-jndi-name>
 <ejb-ref>
 <ejb-ref-name>ejb/StatelessBean</ejb-ref-name>
 <ejb-ref-type>Session</ejb-ref-type>
 <remote>org.jboss.ejb3.test.service.StatelessRemote</remote>
 <ejb-link>StatelessBean</ejb-link>
 <jee:injection-target>
 <jee:injection-target-class>org.jboss.ejb3.test.service.ServiceSix</jee:injection-target-class>
 <jee:injection-target-name>stateless</jee:injection-target-name>
 </jee:injection-target>
 <jndi-name>StatelessBean/remote</jndi-name>
 </ejb-ref>
 <ejb-local-ref>
 <ejb-ref-name>ejb/StatelessLocal</ejb-ref-name>
 <ejb-ref-type>Session</ejb-ref-type>
 <local>org.jboss.ejb3.test.service.StatelessLocal</local>
 <ejb-link>StatelessBean</ejb-link>
 <jee:injection-target>
 <jee:injection-target-class>org.jboss.ejb3.test.service.ServiceSix</jee:injection-target-class>
 <jee:injection-target-name>setStatelessLocal</jee:injection-target-name>
 </jee:injection-target>
 <jndi-name>StatelessBean/local</jndi-name>
 </ejb-local-ref>
 <security-identity>
 <jee:run-as>
 <jee:role-name>role name</jee:role-name>
 </jee:run-as>
 <!-- FIXME
 <run-as-principal>run as principal</run-as-principal>
 -->
 </security-identity>
 <resource-ref>
 <res-ref-name>testDatasource</res-ref-name>
 <res-type>javax.sql.DataSource</res-type>
 <res-auth>Container</res-auth>
 <res-sharing-scope>Shareable</res-sharing-scope>
 <mapped-name>java:/DefaultDS</mapped-name>
 <jee:injection-target>
 <jee:injection-target-class>org.jboss.ejb3.test.service.ServiceSix</jee:injection-target-class>
 <jee:injection-target-name>testDatasource</jee:injection-target-name>
 </jee:injection-target>
 </resource-ref>
 <resource-env-ref>
 <jee:description>A test of the resource-env-ref tag</jee:description>
 <jee:resource-env-ref-name>res/aQueue</jee:resource-env-ref-name>
 <jee:resource-env-ref-type>javax.jms.Queue</jee:resource-env-ref-type>
 <jndi-name>queue/mdbtest</jndi-name>
 </resource-env-ref>
 <message-destination-ref>
 <message-destination-ref-name>messageDestinationRef</message-destination-ref-name>
 <jee:mapped-name>mappedName</jee:mapped-name>
 </message-destination-ref>
 <security-domain>security domain</security-domain>
 <method-attributes>
 <method>
 <method-name>test</method-name>
 <transaction-timeout>1</transaction-timeout>
 </method>
 </method-attributes>
 </service>
 </enterprise-beans>
</jboss>

All elements directly under service are in jboss namespace, I could make an extension on session-beanType, but that would throw the model into a fit.
ejb-ref and ejb-local-ref are pretty consistent.
security-identity somehow defies the xsd I've defined for it, but fits the model.
Then wickedness ensues: resource-ref can't be an extension, because it redefines the usage of mapped-name. It should however be an extension (as resource-env-ref) because now description won't fit the model.
It leads to a mapped-name from a different namespace as shown in message-destination-ref. And thus I can't fit both of them into one unified model. So currently I'm at a stalemate.
Any suggestions?

24. Re: So what does unification mean for the ejb containers

wolfc Oct 17, 2007 5:41 PM (in response to starksm64)

"alex.loubyansky@jboss.com" wrote:
Also currently jboss_5_0.xsd has http://java.sun.com/xml/ns/javaee as the target namespace which I think should be changed to a JBoss one.

I did that and now I'm stuck. Why does it need to change to a JBoss namespace?

25. Re: So what does unification mean for the ejb containers

weston.price Oct 17, 2007 5:49 PM (in response to starksm64)

Again, I brought this up on one of our interminable meetings on Friday. Why are we including the Sun EE namespace in our stuff? Can't we simply use the Sun stuff as a base and then extend it?

26. Re: So what does unification mean for the ejb containers

starksm64 Oct 17, 2007 5:51 PM (in response to starksm64)

This looks ok, what is the problem?

<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://www.jboss.com/xml/ns/javaee"
 xmlns:javaee="http://java.sun.com/xml/ns/javaee"
 xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified"
 attributeFormDefault="unqualified"
 version="5.0">

27. Re: So what does unification mean for the ejb containers

wolfc Oct 18, 2007 9:38 AM (in response to starksm64)

"scott.stark@jboss.org" wrote:
This looks ok, what is the problem?

<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://www.jboss.com/xml/ns/javaee"
 xmlns:javaee="http://java.sun.com/xml/ns/javaee"
 xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified"
 attributeFormDefault="unqualified"
 version="5.0">

No problem there, that's the easy part.

"weston.price@jboss.com" wrote:
Again, I brought this up on one of our interminable meetings on Friday. Why are we including the Sun EE namespace in our stuff? Can't we simply use the Sun stuff as a base and then extend it?

If you mean creating extensions with javaee as the base like this:

<xsd:complexType name="jboss-resource-env-refType">
 <xsd:annotation>
 <xsd:documentation> The resource-env-ref element gives a mapping between the "code name" of a
 env resource (res-ref-name, provided by the Bean Developer) and its deployed JNDI name.
 </xsd:documentation>
 </xsd:annotation>

 <xsd:complexContent>
 <xsd:extension base="javaee:resource-env-refType">
 <xsd:sequence>
 <xsd:element name="jndi-name" type="javaee:jndi-nameType"/>
 </xsd:sequence>
 </xsd:extension>
 </xsd:complexContent>
 </xsd:complexType>

then you're back at the original problem, which is that the Sun xsds don't expose any elements.
So for example there is no jee:description that you can reference when building JBoss elements. Thus unmarshalling will get:

org.jboss.xb.binding.JBossXBRuntimeException: {http://www.jboss.com/xml/ns/javaee}description not found as a child of {http://www.jboss.com/xml/ns/javaee}ejb-ref

Changing the xml will give:

org.xml.sax.SAXException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'jee:description'. One of '{"http://www.jboss.com/xml/ns/javaee":description,
"http://www.jboss.com/xml/ns/javaee":ejb-ref-name,
"http://www.jboss.com/xml/ns/javaee":ejb-ref-type,
"http://www.jboss.com/xml/ns/javaee":home,
"http://www.jboss.com/xml/ns/javaee":remote,
"http://www.jboss.com/xml/ns/javaee":ejb-link,
"http://www.jboss.com/xml/ns/javaee":mapped-name,
"http://www.jboss.com/xml/ns/javaee":injection-target,
"http://www.jboss.com/xml/ns/javaee":jndi-name,
"http://www.jboss.com/xml/ns/javaee":ignore-dependency}' is expected.
@ file:/home/carlo/work/metadata/target/eclipse-classes/org/jboss/test/metadata/ejb/JBoss50_testService.xml[16,30]

Thus ignore-dependency will have an jboss:injection-target, while resource-env-ref will have a javaee:injection-target. If javaee:injection-target was exposed, then ignore-dependency could ref that element and the world would be a better place.

28. Re: So what does unification mean for the ejb containers

starksm64 Oct 18, 2007 1:49 PM (in response to starksm64)

I guess we just need to redefine those javaee types that are not exported.

29. Re: So what does unification mean for the ejb containers

bdecoste Oct 18, 2007 2:59 PM (in response to starksm64)

What am I missing? We should be referencing

<xsd:group ref="javaee:descriptionGroup"/>

or

type="javaee:descriptionType"