Hi Jeff,
Thanks!
That did the trick.
C
To: <[EMAIL PROTECTED]>
"Jeff Rodgers" cc: (bcc: Constantine
Georges/Towers Perrin)
<[EMAIL PROTECTED] Subject: RE: Caching Schemas
int.com>
04/21/2003 05:03
PM
Please respond to
xerces-j-user
If the problem is that the included schemas are not resolved with the
entity resolver, then the following may fix your problem. This code works
whether the schemas are in the filesystem or in a jar. They just need to be
in the classpath. The key I found is the setSystemId() call. This allowed
xerces to "find" the included schema.
public InputSource resolveEntity(String publicID, String systemID)
throws IOException, SAXException
{
System.out.println("SystemID: " + systemID);
String schemaName = systemID.substring(systemID.lastIndexOf
("/"));
if(schemaName != null)
{
InputStream inp = this.getClass
().getResourceAsStream(schemaName);
if(inp == null)
{
return null;
}
else
{
InputSource iSource = new InputSource(inp);
iSource.setSystemId(systemID);
return iSource;
}
}
else
{
return null;
}
}
-----Original Message-----
From: Constantine Georges [mailto:[EMAIL PROTECTED]
Sent: Monday, April 21, 2003 3:53 PM
To: [EMAIL PROTECTED]
Subject: Re: Caching Schemas
Okay -- I have a feeling I'm not explaining my particular problem properly.
The reason I've continued it on this thread is that I think that my and
Glenn's problems are related (as well as Paul Sorenson's, from a few weeks
ago).
(See attached file: ParserTest.java)(See attached file: test.jar)(See
attached file: test.zip)
In this case, I've dummied up a simple example of the include problems I'm
talking about. ParserTest.java creates 2 parsers: one of them is
instructed to load a schema using the made-up "classpath://" protocol, and
the other is instructed to load a schema using the regular "file://"
protocol. I then create a simple ErrorHandler and a simple EntityResolver
to resolve the "classpath://" protocol, and then set the parsers against
Test.xml.
Test.jar is intended to be the "repository"-esque treatment I was
mentioning: Test.xsd (which references T1.xsd and T2.xsd) is instructed to
look for them using the "classpath://" protocol.
Test.zip is a collection of files that can be unzipped into your c:/ drive
(sorry Unix folks -- I wasn't thinking when I wrote the URIs and I'm too
lazy to change them now) where Test.xsd is instructed to look for
sub-schemas using the "file://" protocol.
If you compile and run ParserTest.java and run it using the following (I'm
omitting paths here except for /, which is where I'm expecting the
filesystem versions of these files to live -- If you unzipped the zip to a
different directory then please use that path instead and change Test.xsd
accordingly):
java -classpath test.jar;\;xerces.jar;xmlParserAPIs.jar ParserTest
Note! You should keep the test.jar ahead of the filesystem versions of the
files on the classpath. The whole point of my exercise is to be able to
patch out XSD updates to schemas in a JAR -- if ClassLoader finds the
filesystem-version files first, everything will work fine.
In any case, you should see that the filesystem version parses without
complaints, whereas the JAR version can't resolve certain components -- T1
and T2, both global elements defined in T1.xsd and T2.xsd.
Thanks,
C
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
