On 8/9/2013 1:51 PM, Alan Bateman wrote:
On 08/08/2013 22:57, huizhe wang wrote:
Hi,
The root cause of this issue is that SPECJVM2008 uses a 3rd party
parser XOM 1.1 to convert the output to its canonical form. The XOM
parser directly references to the JDK parser implementation
"SAXParser" with a different configuration than the default JDK
parser, in this case, the DTD-only parser configuration
"DTDConfiguration". In JAXP 1.5, we added XMLSecurityPropertyManager
that is instantiated in the default configuration
"XML11Configuration". Since XMLSecurityPropertyManager is not
supported by DTDConfiguration, XOM no longer works.
I see this has been pushed but just so I understand, but can you
expand on what you mean by "directly references JDK parser
implementation"? I'm just wondering whether it's using the standard
provider interfaces when on the class path or whether it's tied to an
old Xerces interface?
It's not using a standard interface. It goes straight to the
implementation, here's how it's done:
class JDK15XML1_0Parser extends SAXParser {
JDK15XML1_0Parser() throws org.xml.sax.SAXException {
super(new DTDConfiguration());
// workaround for Java 1.5 beta 2 bugs
com.sun.org.apache.xerces.internal.util.SecurityManager manager =
new
com.sun.org.apache.xerces.internal.util.SecurityManager();
setProperty(Constants.XERCES_PROPERTY_PREFIX +
Constants.SECURITY_MANAGER_PROPERTY, manager);
}
}
where:
SAXParser is com.sun.org.apache.xerces.internal.parsers.SAXParser
DTDConfiguration is
com.sun.org.apache.xerces.internal.parsers.DTDConfiguration
And of course, if Xerces jars are on the classpath, these would be:
org.apache.xerces.parsers.SAXParser and
org.apache.xerces.parsers.DTDConfiguration.
It looks up Xerces, then JDK, if failed, it actually falls back to the
SAX interface, that is XMLReaderFactory.
-Joe
-Alan.
