(I didn’t make it).
It complains that it cannot find the class org/apache/xerces/impl/xs/psvi/PSVIProvider which is clearly not there. Was it there in an older library? This seems to suggest that there is some incompatibility between libraries, but I don’t know why it’s occurring now.
Yes, that was the problem. Strange. xercesImpl.jar was in the path, but I had to resort the libraries to get it to be recognised. I knew about this before, but it still strikes me as quite odd.
xercesimpl.jar conflicts with xalan-2.6.0.jar, but I can’t figure out why. xercesimpl.jar must be before xalan in the path. There are some classes that are almost the same, but differ by one letter (e.g., org.apache.xml.serialize(r).Serializer.class) but none of them are exactly the same, so I still don’t quite get it. There can’t possibly be a length limit on directory names, can there?
The only place where the two hierarchies overlap is in org.apache.xml, and
there there aren’t even any classes at that node. I don’t think it’s a
namespace conflict. Anyway, Xalan is an XSLT implmementation and Xerces
is an XML parser. Xalan depends on Xerces, so far as I know.
I was referring to org.apache.xml.serialize(r).Serializer.class for example. The only differences is the “r” in the fourth path name. Wouldn’t they be kind of redundant?
the slight difference should be enough to distinguish them. I just don’t get why a) they’re so similar and b) why there’s a conflict anywhere anyway.
I’ve seen this kind of problem before on other projects. My best guess is this: There’s some class that’s defined in both the xalan and the xerces Jar files. The xalan file was built with a different (older, presumably) version of xerces. Some method in xalan’s version of this duplicated class references org/apache/xerces/impl/xs/psvi/PSVIProvider, a class that’s no longer in the xerces file. The xerces file’s version of the duplicated class doesn’t reference PSVIProvider. Moving xerces to the top of classpath ensures that the correct version of the mystery class is loaded.
This is never a problem except when you try to set up a new
development environment with eclipse, which, by default (and not
unreasonably) sorts the libraries alphabetically. It’s not enough to
get worked up about but perhaps a note should be made about it in the
developers corner regarding how to set up eclipse.
Brent, are you taking care of that page? We may want to update this page anyway.
As for why it happens is completely beyond me. Rodney’s suggestion
sounds reasonable, but there doesn’t appear to be any evidence that
it’s true. There’s no reason why Java cannot find that class even if
you reorder the libraries.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151