Resolving Schemas from the classpath

[Constantine Georges <co...@towers.com>]

Hi all :)

I'm trying to find a way to get schema documents from the active classpath.
That is to say, using ClassLoader.getSystemResourceAsStream().

Using a custom EntityResolver, I craft a special URI that uses the made-up
"classpath://" protocol.  If I find this protocol on the front of the
systemId, I strip off the protocol and ask ClassLoader to find the resource
for me, otherwise I let the regular URI resolver do the work.  If I use the
regular filesystem protocol ("file:///") all the documents in question work
and validate just fine.  The reason I can't rely on the filesystem is that
the process using these schemas will most likely be running out of a JAR
and I don't think I'll have access to the filesystem for creating temporary
files.  The powers that be wanted to leave the possibility of patching
open, however, which is why the classpath has to be searched -- it's
POSSIBLE that the files will be in the filesystem rather than an archive.

The problem is with schemas that have multiple documents <included> in
them.  The resolver works fine, and finds all the files in the classpath.
The problem is that when I try to validate the instance document, Xerces
says that top-level elements that I declare in one schema document and
reference in another can't be found.  So, for instance, in this case:

(The specifics of T1.xsd and T2.xsd are really trivial, and so is the
instance document, so I won't include them.  Just know that T1.xsd declares
a global T1 element, and T2 declares a global T2 element )

// Main Schema doc
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:t="http://www.my.com/Test"
        targetNamespace="http://www.my.com/Test"
        elementFormDefault="qualified">

  <include schemaLocation="classpath://package/name/here/T1.xsd"/>
  <include schemaLocation="classpath://package/name/here/T2.xsd"/>

  <element name="Test" type="t:Test" />

  <complexType name="Test">
     <sequence>
       <element ref="t:T1"/>
       <element ref="t:T2"/>
     </sequence>
  </complexType>

</schema>

The parser emits the following errors:
Error - src-resolve: Cannot resolve the name 't:T1' to a(n) element
declaration component.
Error - src-resolve: Cannot resolve the name 't:T2' to a(n) element
declaration component.
Error - cvc-complex-type.2.4.d: Invalid content starting with element 'T1'.
No child element is expected at this point.

Does anybody know a way around this?

Thanks in advance,
C




---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org

Re: Resolving Schemas from the classpath

[Paul Sorenson <pa...@classware.com.au>]

----- Original Message -----
From: "Constantine Georges" <co...@towers.com>
To: <xe...@xml.apache.org>
Sent: Friday, April 18, 2003 1:19 AM
Subject: Resolving Schemas from the classpath


> I'm trying to find a way to get schema documents from the active
classpath.
> That is to say, using ClassLoader.getSystemResourceAsStream().

> The problem is with schemas that have multiple documents <included> in
> them.  The resolver works fine, and finds all the files in the classpath.
> The problem is that when I try to validate the instance document, Xerces
> says that top-level elements that I declare in one schema document and
> reference in another can't be found.  So, for instance, in this case:

I posted a similar problem the list a few weeks ago although my custom
Entity Resolver was simply using the filesystem.  When I instantiated the
InputSource with a FileReader, only the first level schema would be
recognized, the second level schema (referenced by the first) didn't, in
spite of successfully opening the FileReader.  I fixed it by using the
string constructor for the InputSource - you maybe able to do that by using
file:// or jar:// depending on where you find the entity.

With all due respect to those who provided some responses to my posts, I was
still left with the nagging feeling that this behaviour is buggy but I have
insufficient knowledge about it to make any authoritative comments.

sos


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org