Hi Neil, >From your suggestion, I can get it working with relative path (setting systemId on InputSource is the key thing for Xerces to find the relative path). Thanks a bunch, Neil. But that's only in expanded mode; when I package it in a war file, exactly like you have predicted, getResourceAsStream does not see the document. I try a variation of directories and manifest setting without success ;-((
If I wish to store the schema in the war file as follows: schemas/file_1.xsd schemas/file_2.xsd WEB-INF/classes WEB-INF/lib/*.jar what should I set in the manifest file for getResourceAsStream to see them? and what should I pass into getResourceAsStream? [ I don't know about tax credit, but you are certainly entitled to a round of "virtual" beer ;-))) ] Thanks linh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: December 6, 2002 11:24 AM To: [EMAIL PROTECTED] Subject: RE: EntityResolver question Hi Linh, A couple of things: I notice you say "I also set "schemas" in the manifest so getResourceAsStream should be able to read the document." Are you sure that it actually *does* read the document though? If it hands Xerces a null reference, there's not much it can do... Once you're certain that streams are being handed back to the parser, you should also consider setting the systemId on the InputSource you're passing back. Xerces will use that to absolutize any relative URI's it finds in the file in question. That is, if there's a schemaLocation in the file returned from the War file, then if you had set the systemId on the InputSource corresponding to that file, Xerces would make a better guess as to what absolutizition should look like. So now I have a question: Any chance this help entitles me to some kind of tax credit??? :)) Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] |---------+-----------------------------> | | "Nguyen, Linh" | | | <[EMAIL PROTECTED]| | | adrc.gc.ca> | | | | | | 12/06/2002 10:45 | | | AM | | | Please respond to | | | xerces-j-user | | | | |---------+-----------------------------> >--------------------------------------------------------------------------- ------------------------------------------------------------------| | | | To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> | | cc: | | Subject: RE: EntityResolver question | | | | | >--------------------------------------------------------------------------- ------------------------------------------------------------------| 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] --------------------------------------------------------------------- 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]
