hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-5254) Xinclude setup results in a stack trace
Date Mon, 26 Sep 2011 14:11:26 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114688#comment-13114688

Steve Loughran commented on HADOOP-5254:

The XML parser printout implies that you are running on some linux distribution that has stuck
a copy of xerces into /user/share/java.

XML Parser : org.apache.xerces.jaxp.SAXParserImpl
XML Parser Location: file:/usr/share/java/xercesImpl-2.9.1.jar
Namespace-aware parser : org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
Namespace-aware parser Location: file:/usr/share/java/xercesImpl-2.9.1.jar

Try renaming that file and 
# seeing if that makes the problem goes away
# what shows up in ant -diagnostics for XML parsers once it has been renamed

Given that Xerces 2.9.1 is XML-include-aware, I'm not sure where the real problem lies here.
There is probably another XML parser getting into your application's class path. Have a look
at [http://xml.apache.org/xalan-j/usagepatterns.html] to see if it offers any insight. 

What you can do here is have an entry point, a Main method, that tries to create an XML parser
and not only prints the classname it uses, it gets the URL of it (via .getClass().getClassLoader().getResource("org/apache/xerces/jaxp/SAXParserImpl").getURL().toExternalForm()
); (replacing the resource path with the name of whichever XML parser you get. 

Ant's <whichresource> task can do this for you -just hand it the classpath of your app
and the classname you want to locate

> Xinclude setup results in a stack trace
> ---------------------------------------
>                 Key: HADOOP-5254
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5254
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: conf
>    Affects Versions: 0.20.0, 0.21.0
>         Environment: java version "1.6.0_02"
> Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
> BEA JRockit(R) (build R27.4.0-90-89592-1.6.0_02-20070928-1715-linux-x86_64, compiled
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>         Attachments: hadoop-5254.patch
> seen this in SVN_HEAD, and it was mentioned on the user list in the week. It explains
why my health tests are failing on class.ForName(FSConstants)
> gistration(, storageID=DS-1466307248-, infoPort=8022,
> [sf-startdaemon-debug] java.lang.ExceptionInInitializerError
> [sf-startdaemon-debug] 	at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:76)
> [sf-startdaemon-debug] 	at java.lang.Thread.run(Thread.java:619)
> [sf-startdaemon-debug] Caused by: java.lang.UnsupportedOperationException: This parser
does not support specification "null" version "null"
> [sf-startdaemon-debug] 	at javax.xml.parsers.DocumentBuilderFactory.setXIncludeAware(DocumentBuilderFactory.java:590)

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message