You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Bill Raudabaugh <bi...@adivo.com> on 2003/05/08 21:41:59 UTC
Accessing PSVI through DOM
I've read the doc and looked through the archive of this list for hints on
how to access PSVI through the DOM interface, and while I seem to be very
close to getting it to work, I've hit a brick wall.
The class below is my test case. The XML schema is definitely operating
because the error handler routines are being called for intentional problems
that I've put in my XML for testing. And the cast of the node to ElementPSVI
works fine. But the PSVI information seems doesn't appear to have been
filled in by the validator. All of the nodes show a validity of 0 -> not
known.
I know there are some smart folks out there that have managed to access PSVI
via DOM. If anyone has any ideas on why my validity is always 0 I would
definitely appreciate it.
Bill
import org.apache.xerces.parsers.DOMParser;
import org.apache.xerces.xni.psvi.*;
import org.apache.xerces.impl.xs.psvi.*;
import org.w3c.dom.*;
import org.xml.sax.*;
import java.io.ByteArrayInputStream;
import javax.xml.parsers.*;
public class SchemaTest implements ErrorHandler {
public static void main(String argv[]) throws Exception {
Document doc;
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
factory.setValidating(true);
factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaLanguage
",
"http://www.w3.org/2001/XMLSchema");
factory.setAttribute("http://apache.org/xml/properties/dom/document-class-na
me",
"org.apache.xerces.dom.PSVIDocumentImpl");
DocumentBuilder parser = factory.newDocumentBuilder();
parser.setErrorHandler(new SchemaTest());
String xml = "<scheduler" +
" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" " +
" xsi:noNamespaceSchemaLocation=\"http://adivo.com/Scheduler.xsd\">" +
"<jobs><group><job></job></group></jobs></scheduler>";
ByteArrayInputStream xmlStream = new ByteArrayInputStream(xml.getBytes());
InputSource source = new InputSource(xmlStream);
doc = parser.parse(source);
checkPSVI(doc.getDocumentElement());
}
private static void checkPSVI(Node node) {
ElementPSVI elem = (ElementPSVI) node;
System.out.println(node.getNodeName() + " validity=" +
elem.getValidity());
NodeList children = node.getChildNodes();
int length = children.getLength();
for (int i=0; i < length; i++) {
Node child = children.item(i);
if (child.getNodeType() == Node.ELEMENT_NODE)
checkPSVI(child);
}
}
public void warning(SAXParseException ex) {
System.out.println(ex.toString());
}
public void error(SAXParseException ex) {
System.out.println(ex.toString());
}
public void fatalError(SAXParseException ex) {
System.out.println(ex.toString());
}
}
Bill Raudabaugh
Adivo Ltd
email: bill@adivo.com
Phone: (614)766-6870
Fax: (614)573-7101
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
RE: Accessing PSVI through DOM
Posted by Bill Raudabaugh <bi...@adivo.com>.
Michael,
Thanks for the suggestions. I did end creating the DOMParser directly and
passing it XML11Configuration which immediately caused a very nasty
java.lang.Verify error. This is the kind of error you get when there is a
version mismatch between what something was compiled against and what it is
running against. Xerces in this case.
Someone should smack my hands for trying to switch in Xerces 2.4 into my
Cocoon 2.0 environment which was built against Xerces 2.1.
Anyway, I'm giving Cocoon 2.1 a try, which is based on Xerces 2.4, instead
of trying to rebuild Cocoon 2.0.4. At least my test case is happy with the
Cocoon 2.1 classpath. But I've got a bit of work yet to do to convert my
application over to Cocoon 2.1 before I'll get to see all the moving parts
working.
Cheers,
Bill
-----Original Message-----
From: Michael Rafael Glavassevich [mailto:mrglavas@engmail.uwaterloo.ca]
Sent: Thursday, May 08, 2003 10:37 PM
To: xerces-j-user@xml.apache.org
Subject: RE: Accessing PSVI through DOM
Hi Bill,
One possibility is that the version of Xerces loaded in your test case may
be different than the one loaded by Cocoon. Maybe Cocoon is using its own
ClassLoader to load Xerces from some other location than your classpath.
org.apache.xerces.parsers.StandardParserConfiguration was the default
configuration in older versions such as Xerces 2.1.0. Are you using
some version of JDK 1.4? That could be the source of the problem.
or...
Perhaps Cocoon has changed the default parser configuration. The logic
used by Xerces to select a parser configuration is described at
http://xml.apache.org/xerces2-j/faq-xni.html#faq-2. The
org.apache.xerces.xni.parser.XMLParserConfiguration system property takes
precedence over other locations, so if you've set the property it should
instantiate the configuration of your choice (provided that Cocoon doesn't
change this value before it reads yours). Try setting this property to
org.apache.xerces.parsers.XML11Configuration, and then check the actual
configuration created for the DOMParser.
Hope that helps.
-----------------------------
Michael Glavassevich
mrglavas@engmail.uwaterloo.ca
4B Computer Engineering
University of Waterloo
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
RE: Accessing PSVI through DOM
Posted by Michael Rafael Glavassevich <mr...@engmail.uwaterloo.ca>.
Hi Bill,
One possibility is that the version of Xerces loaded in your test case may
be different than the one loaded by Cocoon. Maybe Cocoon is using its own
ClassLoader to load Xerces from some other location than your classpath.
org.apache.xerces.parsers.StandardParserConfiguration was the default
configuration in older versions such as Xerces 2.1.0. Are you using
some version of JDK 1.4? That could be the source of the problem.
or...
Perhaps Cocoon has changed the default parser configuration. The logic
used by Xerces to select a parser configuration is described at
http://xml.apache.org/xerces2-j/faq-xni.html#faq-2. The
org.apache.xerces.xni.parser.XMLParserConfiguration system property takes
precedence over other locations, so if you've set the property it should
instantiate the configuration of your choice (provided that Cocoon doesn't
change this value before it reads yours). Try setting this property to
org.apache.xerces.parsers.XML11Configuration, and then check the actual
configuration created for the DOMParser.
Hope that helps.
-----------------------------
Michael Glavassevich
mrglavas@engmail.uwaterloo.ca
4B Computer Engineering
University of Waterloo
On Thu, 8 May 2003, Bill Raudabaugh wrote:
> Ok, the plot thickens. While my test case works with the classpath changed,
> my application exhibits the original problem regardless of how much path
> twiddling I do. My application is running in Cocoon while my test case runs
> standalone. I do suspect that there may be something in the Cocoon classes
> that are affecting this.
>
> I've found in my test case that when it is working
> parser.DOMParser.fConfiguration is pointing at
> org.apache.xerces.parsers.XML11Configuration. This is good since this is
> expecting XML Schema validation. But when it is not working, for some reason
> parser.DOMParser.fConfiguration is point at
> org.apache.xerces.parsers.StandardParserConfiguration.
>
> Why would the same code produce two different configurations? How can I
> ensure that the XML11Configuration is always used?
>
> -----Original Message-----
> From: Bill Raudabaugh [mailto:bill@adivo.com]
> Sent: Thursday, May 08, 2003 3:49 PM
> To: xerces-j-user@xml.apache.org
> Subject: RE: Accessing PSVI through DOM
>
>
> Good grief! It was a classpath problem ....
>
> [snip]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
RE: Accessing PSVI through DOM
Posted by Bill Raudabaugh <bi...@adivo.com>.
Ok, the plot thickens. While my test case works with the classpath changed,
my application exhibits the original problem regardless of how much path
twiddling I do. My application is running in Cocoon while my test case runs
standalone. I do suspect that there may be something in the Cocoon classes
that are affecting this.
I've found in my test case that when it is working
parser.DOMParser.fConfiguration is pointing at
org.apache.xerces.parsers.XML11Configuration. This is good since this is
expecting XML Schema validation. But when it is not working, for some reason
parser.DOMParser.fConfiguration is point at
org.apache.xerces.parsers.StandardParserConfiguration.
Why would the same code produce two different configurations? How can I
ensure that the XML11Configuration is always used?
-----Original Message-----
From: Bill Raudabaugh [mailto:bill@adivo.com]
Sent: Thursday, May 08, 2003 3:49 PM
To: xerces-j-user@xml.apache.org
Subject: RE: Accessing PSVI through DOM
Good grief! It was a classpath problem ....
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
RE: Accessing PSVI through DOM
Posted by Bill Raudabaugh <bi...@adivo.com>.
Good grief! It was a classpath problem ....
-----Original Message-----
From: Bill Raudabaugh [mailto:bill@adivo.com]
Sent: Thursday, May 08, 2003 3:42 PM
To: xerces-j-user@xml.apache.org
Subject: Accessing PSVI through DOM
I've read the doc and looked through the archive of this list for hints on
how to access PSVI through the DOM interface, and while I seem to be very
close to getting it to work, I've hit a brick wall.
The class below is my test case. The XML schema is definitely operating
because the error handler routines are being called for intentional problems
that I've put in my XML for testing. And the cast of the node to ElementPSVI
works fine. But the PSVI information seems doesn't appear to have been
filled in by the validator. All of the nodes show a validity of 0 -> not
known.
I know there are some smart folks out there that have managed to access PSVI
via DOM. If anyone has any ideas on why my validity is always 0 I would
definitely appreciate it.
Bill
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org