Maybe if I explain the problem a little more then you can help me...
In development, I set the property ".../external-noNamespaceSchemaLocation"
to a full pathname on the disk. Xerces does resolve the types defined in
the xsd:include schema file. I don't have any problem then.
But when I create a war file for production, I can't use
".../external-noNamespaceSchemaLocation" if I want to distribute the schema
INSIDE the war file. I try getResourceAsStream in an EntityResolver and get
up to the point where Xerces no longer complains about missing document, but
I still get src-resolve errors for component defined in the xsd:include
files.
Here is an excerpt from my resolveEntity:
InputStream inputStream = null;
if (systemID.endsWith("layout.xsd")) {
inputStream =
Parser.class.getResourceAsStream("/schemas/layout_internal.xsd");
return new InputSource(inputStream);
}
else if (systemID.endsWith("simple_internal.xsd")) {
inputStream =
Parser.class.getResourceAsStream("/schemas/simple_internal.xsd");
return new InputSource(inputStream);
}
{..etc..}
where "layout_internal.xsd" is the top-level document, "simple_internal.xsd"
is one of xsd:include file. I also set "schemas" in the manifest so
getResourceAsStream should be able to read the document.
I find that if I copy all the definitions into the top-level schema file
"layout_internal.xsd", then Xerces can resolve them, but I don't want to do
that (the schema consists several dozen files and I don't own them)
TIA
linh
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: December 5, 2002 4:21 PM
To: [EMAIL PROTECTED]
Subject: RE: EntityResolver question
Hi Benson and Linh,
The reason Xerces now returns fully-expanded URI's to the Entity resolver
is that SAX quite explicitly states that this is what XML processors are
supposed to do. The behaviour in 1.4.4 was a bug.
The most portable behaviour is to use absolute URI's in your schema, then
map them in your Entity resolver to whatever you need them to point at;
this way, your entity resolver will be presented with the same URI on
whatever platform it's running, and can do what it needs to do to find the
document.
Note that if Xerces can't find a schema document, in most cases it will
send a warning callback to the error handler registered on the parser; if
you get one of these, chances are you'll be seeing error messages about
undefined components later on in the parse. :)
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | "Benson Cheng" |
| | <[EMAIL PROTECTED]|
| | core.net> |
| | |
| | 12/05/2002 04:11 |
| | PM |
| | Please respond to|
| | xerces-j-user |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------
------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: RE: EntityResolver question
|
|
|
|
|
>---------------------------------------------------------------------------
------------------------------------------------------------------|
This is how I get it to working now, in 1.4.4 I was using relative schema
file path to set the property (".../external-noNamespaceSchemaLocation"),
and let the EntityResolver to insert the parent path then read the schema
file. In 2.2.1, I have to use the full file path to set the property, then
xerces consider this full path as the current working folder, so I have to
change xsd:include from "common/common.xsd" to "../../common/common.xsd",
then xerces automatically resolve this path for you. Not sure this is good
or not, but this is how I get it working. BTW, it does resolve the types
defined in the xsd:include schema file.
Hope this help.
Benson.
-----Original Message-----
From: Nguyen, Linh [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 05, 2002 12:47 PM
To: '[EMAIL PROTECTED]'
Subject: RE: EntityResolver question
I get around the problem you described by parsing the systemId and
stripping
off the unwanted prefix. But the problem I run into then is Xerces does
not
resolve any type defined in the included xsd files, i.e. I find that it
works only if the schema are flattened into one single file, which is
unacceptable if you don't have control over the schema yourself.
Any input is certainly appreciated. [ I don't mean to steal this thread,
Benson, mine is just another related problem you might run into as well
when
using EntityResolver ]
-----Original Message-----
From: Benson Cheng [mailto:[EMAIL PROTECTED]
Sent: December 5, 2002 1:27 PM
To: [EMAIL PROTECTED]
Subject: EntityResolver question
I am switching Xerces from 1.4.4 to 2.2.1 and running to a EntityResolver
problem. In my schema contains the following line
<xsd:include schemaLocation="common/common.xsd"/>
in xerces 1.4.4, when the resolveEntity() get called, the parameter
systemId
pass in as "common/common.xsd", its a relative path so I can insert a
parent
path base on a configurable value. But in 2.2.1 version, it pass in as
"file:///D:/work/test/common/common.xsd" value, d:/work/test is the current
directory. Is there way to make the 2.2.1 pass the value as is? or do I
have to change the schemaLocation attribute in all my schemas?
thanks,
Benson.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
