#141 XML error at startup

[Bob Jacobsen]

Three different users have reported a problem with verison 1.7.2 that
has be stumped.

All are using XP; two are using XP Pro, and I don't know about the
third. All three are new installs, or reinstalls after a very long period of
no use (e.g. XP probably updated during the time) All three of the
people who've encountered this problem were using Java 1.4, and one
was able to fix it by installing Java 1.5; another fixed it by reinstalling
1.7.1, and the third is still stuck. (Do we have anybody using 1.7.2 on
XP Pro with Java 1.4 successfully?)

All three seem to have working java comm libraries, because they can
see the comm ports and write what looks to be a fine configuration file.
But the next time they start up, the initialization fails with the error
(simplified; see at the end for the whole thing):

10 configurexml.ConfigXmlManager ERROR - Exception
reading: org.jdom
.JDOMException: Error on line 2 of document
file:/C:/Program%20Files/JMRI/xml/DT
D/: External entity not found:
"file:/C:/Program%20Files/JMRI/xml/DTD/layout-con
fig.dtd". [main]
org.jdom.JDOMException: Error on line 2 of document
file:/C:/Program%20Files/JMR
I/xml/DTD/: External entity not found:
"file:/C:/Program%20Files/JMRI/xml/DTD/la
yout-config.dtd".
at org.jdom.input.SAXBuilder.build(SAXBuilder.java)

... (while reading the DecoderProConfig2.xml startup config file)

What seems to be happening is that the XML processing is behaving
differently on these machines, which causes the failure.

For several reasons, JMRI does _not_ keep the DTD files in the same
directory as the xml files they describe. But we do write DOCTYPE lines
that look like:

<!DOCTYPE layout-config SYSTEM "layout-config.dtd">

Then, when reading XML files, we use the form that takes both the file
(as a stream) and a specific URL to use as a base for the DTD:

String dtdpath = "xml"+File.separator+"DTD"+File.separator;
File dtdFile = new File(dtdpath);
String dtdUrl = jmri.util.FileUtil.getUrl(dtdFile);
// Open and parse file
SAXBuilder builder = new SAXBuilder(verify); // argument
controls validation
Document doc = builder.build(new BufferedInputStream
(stream),dtdUrl);

The problem is encountered here, because the trace shows that we're
inside that "build()" call.

The only thing that's really changed in this area of the code is the
"verify" value; it controls whether the file contents are checked against
the DTD. It used to default to "true" (do the check), and is 1.7.2 was
changed to "false". It could be that switching to not-verifying has
provoked some other error on just these machines.

It could also be the generation or the handling of the URL for the DTD.

I'm not sure what that DTD URL should look like on an XP machine. Is
the handling of "C:" right in the URL from the error message: file:/C:/
Program%20Files/JMRI/xml/DTD/ ?

The "%20" seems right, because that's how you code a space in a URL,
but perhaps some systems can handle it and some can't?

The URL is generated by jmri.util.FileUtil.getUrl, which is a front end
that handles different methods being available in different JVMs:

static public String getUrl(File file) {
try {
return file.toURI().toURL().toString();
} catch (NoSuchMethodError e2) { // File.toURI first available in
Java 1.4
try {
return file.toURL().toString();
} catch (NoSuchMethodError e3) { // File.toURL not in 1.1.8
if (file.isDirectory())
return "file:"+file.getAbsolutePath()+File.separator;
else
return "file:"+file.getAbsolutePath();
} catch (Throwable e) {
if (log.isDebugEnabled()) log.debug(" Exception 1: "+e);
return "file:"+file.getAbsolutePath()+File.separator;
}
} catch (Throwable e) {
if (log.isDebugEnabled()) log.debug(" Exception 2: "+e);
return "file:"+file.getAbsolutePath()+File.separator;
}
}

This attempts to use a method that's not available before 1.4 (but
should be available in 1.5 too); if that fails, it drops back.

It could be that the toURI().toURL() approach doesn't work on 1.4 (but
would have to have started working on 1.5), but only on certain
machines?

Or could it be something like various machines providing their own
SAX (or JDOM?) libraries which are coming in front of ours?

As you can see, I'm just completely stuck on this. Without a local
machine that can reproduce it, I'm not doing much more than
speculating and Googling. But I'd really like to fix it, because I suspect
that there's a larger underlying issue.

Is there anybody who can reproduce this? Or who's encountered it or
something like it?

Thanks in advance.

Bob

Full trace:

10 configurexml.ConfigXmlManager ERROR - Exception
reading: org.jdom
.JDOMException: Error on line 2 of document
file:/C:/Program%20Files/JMRI/xml/DT
D/: External entity not found:
"file:/C:/Program%20Files/JMRI/xml/DTD/layout-con
fig.dtd". [main]
org.jdom.JDOMException: Error on line 2 of document
file:/C:/Program%20Files/JMR
I/xml/DTD/: External entity not found:
"file:/C:/Program%20Files/JMRI/xml/DTD/la
yout-config.dtd".
at org.jdom.input.SAXBuilder.build(SAXBuilder.java)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java)
at jmri.jmrit.XmlFile.rootFromStream(Unknown Source)
at jmri.jmrit.XmlFile.rootFromFile(Unknown Source)
at jmri.configurexml.ConfigXmlManager.load(Unknown Source)
at apps.Apps.<init>(Unknown Source)
at apps.DecoderPro.DecoderPro.<init>(Unknown Source)
at apps.DecoderPro.DecoderPro.main(Unknown Source)
Root cause: java.io.IOException: The parameter is incorrect
at org.apache.crimson.parser.Parser2.fatal(Unknown Source)
at
org.apache.crimson.parser.Parser2.externalParameterEntity(Unknown
Sou
rce)
at org.apache.crimson.parser.Parser2.maybeDoctypeDecl
(Unknown
Source)
at org.apache.crimson.parser.Parser2.parseInternal(Unknown
Source)
at org.apache.crimson.parser.Parser2.parse(Unknown Source)
at org.apache.crimson.parser.XMLReaderImpl.parse(Unknown
Source)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java)
at jmri.jmrit.XmlFile.rootFromStream(Unknown Source)
at jmri.jmrit.XmlFile.rootFromFile(Unknown Source)
at jmri.configurexml.ConfigXmlManager.load(Unknown Source)
at apps.Apps.<init>(Unknown Source)
at apps.DecoderPro.DecoderPro.<init>(Unknown Source)
at apps.DecoderPro.DecoderPro.main(Unknown Source)
Root cause: java.io.IOException: The parameter is incorrect
at org.apache.crimson.parser.Parser2.fatal(Unknown Source)
at
org.apache.crimson.parser.Parser2.externalParameterEntity(Unknown
Sou
rce)
at org.apache.crimson.parser.Parser2.maybeDoctypeDecl
(Unknown
Source)
at org.apache.crimson.parser.Parser2.parseInternal(Unknown
Source)
at org.apache.crimson.parser.Parser2.parse(Unknown Source)
at org.apache.crimson.parser.XMLReaderImpl.parse(Unknown
Source)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java)
at jmri.jmrit.XmlFile.rootFromStream(Unknown Source)
at jmri.jmrit.XmlFile.rootFromFile(Unknown Source)
at jmri.configurexml.ConfigXmlManager.load(Unknown Source)
at apps.Apps.<init>(Unknown Source)
at apps.DecoderPro.DecoderPro.<init>(Unknown Source)
at apps.DecoderPro.DecoderPro.main(Unknown Source)
1112 jmri.ProgServiceModePane WARN - No programmer
available, so
modes not set [main]
31546 jmri.ProgServiceModePane WARN - No programmer
available, so
modes not set [main]

[Bob Jacobsen]

Logged In: YES
user_id=204021

Current thinking: This is an deficiency in the Xerces parser we distribute,
which can't handle the full URI/URN that suddenly appears with Java 1.4 and
the current FileUtil.

Can workaround by using a relative DTD path in XmlFile, which is now out to
test with some users.

Note that FileUtil is also used to locate/play sounds, and java help. These
also need to be checked.

[Bob Jacobsen]

Logged In: YES
user_id=204021

Significant new code to retry this a couple ways and notify will be in 1.7.3; here's
hoping.

[SourceForge Robot]

Logged In: YES
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).