[jdom-interest] B-7's MANIFEST.MF and newer versions of Xerces =
jhunter at collab.net
Mon Sep 17 16:41:34 PDT 2001
It was our belief when adding that MANIFEST entry that it only affected
the JAR when used as:
java -jar jdom.jar
and wouldn't affect the JAR's behavior when just placed in the CLASSPATH
environment variable. I think testing bore that out, too. But this may
be different on different JVMs and on different systems, and perhaps
depending on usage. For example:
Seems to imply the various Class-path entries should be combined in a
JDK 1.3 environment.
Does anyone know more about this? What we're trying to do is let you
run "java -jar jdom.jar" and have it work, which requires at least some
parser be present.
"Jan C. Zawadzki" wrote:
> I've just spent several days tracking a nasty CLASSPATH problem created
> by an entry in the Beta 7 MANIFEST.MF entry.
> Basically the current jdom.jar will try to load the version of xerces it
> ships with - which creates CLASSPATH positioning dependencies that are a
> PAIN to track down.
> To fix:
> in package/META-INF/MANIFEST.MF, third line:
> > Class-Path: ../lib/xerces.jar xerces.jar
> remove the ../lib/xerces.jar bit.
> What makes this so evil is that the JVM's under Linux resolve symbolic
> links. When an symbolic link to jdom.jar is placed in some project's
> lib directory, both Linux JVM's still load the ../lib/xerces.jar
> RELATIVE to the REAL jdom.jar file - hence forcing the load of the
> xerces file shipped with the jdom package. If jdom.jar appears prior to
> the newer version of Xerces, bad things happen.
> To be honest I don't understand the rationale for placing this line
> there in the first place. If the user can put jdom's jar file in the
> classpath, they can also put xerces there. Using the class-path entry
> in the manifest file hides classpath behaviour, and makes debugging
> related problems much harder...
> To control your jdom-interest membership:
More information about the jdom-interest