Schema Includes

[adrian.brock]

I've hit a problem trying to do this:
http://jira.jboss.com/jira/browse/JBMICROCONT-42

To see the problem, look at the SchemaIncludeUnitTestCase

I don't know whether this is a Xerces bug or a problem with the
way the schema resolving works?

[adrian.brock]

If you decide it is a bug, can you link it to the above task. Thanks

[aloubyansky]

This comes from Xerces.

[adrian.brock]

I'm not sure that is true, I think it is an issue with the
singleton schema resolver.

I've reduced the test to a minimum.

If I change the namespace(s) to
"urn:jboss:bean-deployer:3.0"
or change the type name to "deploymentTypeX"
I don't see the problem?

[aloubyansky]

I am looking into this right now.

[aloubyansky]

Yes, it's schema resolution. If you enable trace for JBossEntityResolver running the test you should see

"Found entity systemId=urn:jboss:bean-deployer:2.0 fileName=bean-deployer_2_0.xsd"

So, the schemaLocation is ignored and pre-registered XSD in the resolver is used instead.

[adrian.brock]

So this creates a problem if I want to split a namespace across schemas.
e.g.
deployment in bean-deployer_2_0.xsd
beans in bean-beans_2_0.xsd (included by deployment)

Shouldn't the schemaLocation overwrite the resolver,
or is this happening inside Xerces?

[adrian.brock]

I added a printStackTrace to resolveEntity.

This looks to be due to hack in the way JBossEntityResolver works???

java.lang.Throwable: Resolve null urn:jboss:bean-deployer:2.0
 at org.jboss.util.xml.JBossEntityResolver.resolveEntity(JBossEntityResolver.java:223)
 at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.getInputSource(DefaultSchemaResolver.java:304)
 at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.resolveAsLSInput(DefaultSchemaResolver.java:281)
 at org.jboss.xb.binding.Util$1.resolveResource(Util.java:462)
 at org.apache.xerces.util.DOMEntityResolverWrapper.resolveEntity(Unknown Source)
 at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
 at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source)
 at org.apache.xerces.impl.xs.traversers.XSDHandler.resolveSchema(Unknown Source)
 at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
 at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source)
 at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
 at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
 at org.apache.xerces.impl.xs.XSLoaderImpl.loadURI(Unknown Source)
 at org.jboss.xb.binding.Util.loadSchema(Util.java:361)
 at org.jboss.test.xml.SchemaIncludeUnitTestCase.testSimpleInclude(SchemaIncludeUnitTestCase.java:43)

It is being passed the namespace as the system id
which resolveSystemId() is checking as a public id

 // Try to resolve the systemId as an entity key
 String filename = null;
 if( localEntities != null )
 filename = (String) localEntities.get(systemId);
 if( filename == null )
 filename = (String) entities.get(systemId);

[adrian.brock]

This is a change that Scott made as part of this:
http://jira.jboss.com/jira/browse/JBAS-2282

http://fisheye.jboss.org/changelog/JBoss?cs=Branch_4_0:starksm:20050923151832

[aloubyansky]

Right. That's our resolution.

[adrian.brock]

It doesn't explain why Xerces is making is resolution requests
when I've told it schema location?

I'll try to make a pure Xerces test without the JBossEntityResolver.

[aloubyansky]

About schemaLocation. OTOH, schemaLocation could point to a remote location while there is a local copy of the schema. Which might be considered as an optimization and/or a workaround to run offline.

[aloubyansky]

I've already done that. If resource resolver is set then it can choose what location to use: the value of schemaLocation or another one.

[adrian.brock]

Ok. But it removes the ability to break a schema into logical chunks.
I would think when we move the parsing of j2ee schemas to
JBossXB it will suffer from the same problem?

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://java.sun.com/xml/ns/javaee"
 xmlns:javaee="http://java.sun.com/xml/ns/javaee"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified"
 attributeFormDefault="unqualified"
 version="3.0">
 <xsd:annotation>
 <xsd:documentation>
 @(#)ejb-jar_3_0.xsds 1.50 02/07/06
 </xsd:documentation>
 </xsd:annotation>

 <xsd:annotation>
 <xsd:documentation>

 Copyright 2003-2006 Sun Microsystems, Inc.

<snip/>

 <xsd:include schemaLocation="javaee_5.xsd"/>

[starksm64]

There is also an xml calatalog requirement that needs to be considered. webservices require that one can use a deployment (?) OASIS catalog as far as I remember.