Support for non-validating parsers

[Hugo Duncan]

I see that the question of supporting non-validating parsers has come up several times in the past, but searching the archives I have not found a solution.

Would it not be possible to catch the javax.xml.parsers.ParserConfigurationException that is thrown if the parser does not support validation and produce a warning, rather than refusing to run?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=53430&messageID=107444#107444

[Alexandru Popescu]

On 12/14/06, Hugo Duncan <testng...@opensymphony.com> wrote:
>
> I see that the question of supporting non-validating parsers has come up several times in the past, but searching the archives I have not found a solution.
>
> Would it not be possible to catch the javax.xml.parsers.ParserConfigurationException that is thrown if the parser does not support validation and produce a warning, rather than refusing to run?

I am a bit confused as SAXParserFactory.setValidating() doesn't throw,
so I don't think this would really help. Do you have a test case that
would reproduce the problem so that I can further investigate?

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

[Mark Derricutt]

Alex - easiest way I've seen to trigger this is add saxon to the class path and watch testng fall over like a drunkard...

Mark

[Alexandru Popescu]

I have added saxon8.jar and saxon8-dom.jar and everything run
correctly. Is it something else I should do?

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

[Hugo Duncan]

Alex,

Thanks for looking at this. I'm confused too, but sometimes that seems normal :-)

The attached project gives the following stack trace when run under eclipse:

javax.xml.parsers.ParserConfigurationException: validation is not supported
at org.gjt.xpp.jaxp11.SAXParserFactoryImpl.newSAXParser(SAXParserFactoryImpl.java:100)
at org.testng.xml.Parser.parse(Parser.java:138)
at org.testng.TestNG.setTestSuites(TestNG.java:445)
at org.testng.eclipse.runner.RemoteTestNG.main(RemoteTestNG.java:119)

---------------------------------------------------------------------
Posted via Jive Forums

http://forums.opensymphony.com/thread.jspa?threadID=53430&messageID=107458#107458

[Mark Derricutt]

Hmmm - when I had the problem I had an earlier saxon in the path, maybe they've upgraded the old parser they had..

[Alexandru Popescu]

On 12/14/06, Mark Derricutt <ma...@talios.com> wrote:

> Hmmm - when I had the problem I had an earlier saxon in the path, maybe
> they've upgraded the old parser they had..
>

If you figure out a way to reproduce it please let me know and I will
try it myself. Meanwhile I am looking at the project Hugo sent -
thanks a lot Hugo! Much appreciated.

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

> On 12/14/06, Alexandru Popescu <

[Alexandru Popescu]

Hugo I think something is wrong with this parser because even if I
make it non-validation it still doesn't work:

[stack]
org.gjt.xpp.XmlPullParserException: <![DOCTYPE declarations not
supported at line 1 and column 58 seen ...!DOCTYPE suite SYSTEM
"http://testng.org/testng-1.0.dtd"... (parser state UNKNONW_EVENT
(-1))
[/stack]

So before jumping to any conclusions, I will wait for another
scenario. However thanks a lot.

[Steve Loughran]

On 14/12/06, Alexandru Popescu <the.mindstor...@gmail.com> wrote:
>
> Hugo I think something is wrong with this parser because even if I
> make it non-validation it still doesn't work:
>
> [stack]
> org.gjt.xpp.XmlPullParserException: <![DOCTYPE declarations not
> supported at line 1 and column 58 seen ...!DOCTYPE suite SYSTEM
> "http://testng.org/testng-1.0.dtd"... (parser state UNKNONW_EVENT
> (-1))
> [/stack]
>
> So before jumping to any conclusions, I will wait for another
> scenario. However thanks a lot.
>

Might be good to explicitly look for parsers, rather than just take
what you are given. For example, I look for Apache Xerces then
sun-redist-Xerces.

public static XMLReader createBaseXercesInstance() throws SAXException {
XMLReader xerces = null;
try {
xerces = XMLReaderFactory.createXMLReader(PARSER_XERCES);
} catch (SAXException e) {
log.debug("Failed to find Xerces", e);
xerces = XMLReaderFactory.createXMLReader(PARSER_JAVA_15);
}
return xerces;
}

where

String PARSER_JAVA_15 = "com.sun.org.apache.xerces.internal.parsers.SAXParser";
and
String PARSER_XERCES = "org.apache.xerces.parsers.SAXParser"

Of course, it means my code only works with xerces on java1.4 and
below. I've made that decision to reduce test/support effort.

Ant only supports junit test runs with the XML listener when Xerces on
the classpath. It may work in other situations, but is "unsupported",
meaning all bugreps get ignored.

[Alexandru Popescu]

We are doing something similar:

[code]
SAXParserFactory spf = null;
Exception cause= null;
try {
spf = SAXParserFactory.newInstance();
}
catch(FactoryConfigurationError ex) {
// If running with JDK 1.4
try {
Class cl =
Class.forName("org.apache.crimson.jaxp.SAXParserFactoryImpl");
spf = (SAXParserFactory) cl.newInstance();
}
catch(Exception ex2) {
cause= ex2;
ex2.printStackTrace();
}
}
if(null == spf) throw new TestNGException("Cannot initialize a
SAXParserFactory", cause);
[/code]

but the above problem doesn't seem to be cause by us. Or are you
saying that instead of SAXParserFactory.newInstance(); we should in
fact try to do something like:

ClassHelper.forName("com.sun.org.apache.xerces.internal.parsers.SAXParser");
spf= cls.newInstance();

?

[Steve Loughran]

That looks pretty much what org.xml.sax.helpers.XMLReaderFactory
appears to do once you step through it, with some plug ins for
classloaders and a system property to set the classname. But yes,
looking for classes by name gives you the ability to prioritise, with
xerces redist at the top, sun xerces after and crimson at the bottom,
if you support it at all.

The SAXParserFactory.newInstance() code looks for some system
property, and service definition in META-INF/services, before falling
back to the JVM's own parser. There's a lot to go wrong, especially
with endorsed directories. Having a list of parsers you want and
selecting an order puts you back in control. You could still let the
system property javax.xml.parsers.SAXParserFactory provide an override
classname if you want end users to choose their parser, but trying to
have the JVM work out for itself which parser is better, well, would
you trust the people who shipped Crimson? That and the SOAP stack in
the 6.0 JVM will go down in history as the biggest bits of code they
should have left out.

-steve

[Hugo Duncan]

Not being an XML parser expert I am not sure how to respond to that. The pull-parser is however a dependency of apache abdera-client, so any test for a project that pulls in this library fails :-(

The suggestion of being able to specify a preferred sequence of parsers would certainly seem to be a way around the issue.

Many thanks,
Hugo

---------------------------------------------------------------------
Posted via Jive Forums

http://forums.opensymphony.com/thread.jspa?threadID=53430&messageID=107796#107796

[Alexandru Popescu]

Hugo I have already committed something in the SVN trunk so if you can
build TestNG version from there it would be great.

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator