Community
Participate
Working Groups
This is perhaps the biggest mess in Eclipse and, given the widespread use of XML, the most ubiquitous. Here are typical errors: - User puts xerces in, e.g., jre/lib/endorsed folder. Eclipse won't run. - Plugin tries to use its own version of xerces. Can't load classes. The first problem is that Eclipse has not taken adequate care to load the version of xerces it depends on. The second is that it has not taken adequate care to keep its version of xerces from leaking into a classloader all plugins inherit. Users should not have to jump through hoops to get xerces to work, Eclipse should jump through hoops to keep from causing this kind of problem. One solution is for Eclipse platform plugins to use a special classloader for xerces only, that is never put in the parent chain other plugins can inherit.
Verified on Mac OS X as well by Jerry.Wilcox@ucop.edu
The thing is that due tu this problem jdom wont work in a plugin, because it can not find any xerces it needs if one want to force jdom not using crimson (because crimson does not supports xml schemas) . its a classpath problem, i get an <br> <br> java.lang.ClassNotFoundException: org.apache.xerces.parsers.SAXParser at org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:121) <br> <br> error in jdom from this lines :<br> <br> SAXBuilder builder = new SAXBuilder("org.apache.xerces.parsers.SAXParser", validate);<br> Document doc = builder.build(instr);<br> <br> althought this:<br> new org.apache.xerces.parsers.SAXParser() ; <br> <br> works without problems. maybe the problem comes from the old and outdated jaxb version in the eclipses xerces plugin which aparently overwrites the jdk1.4. jaxb implementation. the problem are the lines : return (XMLReader) NewInstance.newInstance(className);<br> in the org.xml.sax.helpers.XMLReaderFactory class they simpley dont find any xerces (not the eclipse-xerces-plugin one nor a additional one that i delivered with my plugin )
We use JDom in Insectivore successfully. I don't think we do anything special, but you can check the source at http://cvs.zclipse.org/cgi-bin/viewcvs.cgi/zclipse/org.zclipse.insectivore/ mike
*** Bug 39485 has been marked as a duplicate of this bug. ***
*** Bug 40472 has been marked as a duplicate of this bug. ***
We distribute a Java-based API and turnkey system that is used by customers on various versions of Java, going back to 1.2. We are now adding XML support to our product, and wish to distribute the Xerces libraries with the product. We also expect our developer customers to rely heavily upon Eclipse. Many of our customers, however, are only interested in using the turnkey products and may not know much about Java. This creates a quandary for us. We would normally install the Xerces JAR files automatically into the jre/lib/ext directory, to aid our non-developer users. But for our developer customers who choose to use the same JSDK as Eclipse, this prevents Eclipse from starting (ClassCastException in .log file). We can't suggest that our users install the JAR files into the jre/lib/endorsed folder (as bug #19252 recommends), as it is not supported by Java versions prior to 1.4. Adding the Xerces classes to our own JAR files makes them larger than we would like (one of our turnkey products is an applet). Requiring the user to include additional JAR files in the classpath is cumbersome, as they may have already deployed applications of their own using just the one JAR file and be resistant to changing their procedures for us. However, right now that seems to be our best choice.
Is there any movement on this bug? A solution to this is dead simple - use a special jar classloader for all internal uses of Xerces. It will thus not appear in the plugin classloader chain(s) at all and it will be insensitive to what is installed in the JRE. This approach means that people who depend on the current behavior will have to change. What better time than 3.0, when APIs are breaking all over the place, to fix it?
To be able to install and use Xerces from ASF or Eclipse side by side, you may try to set the context classloader with this statement (before you try to use any Xerces factory): currentThread.setContextClassLoader(my.xerces.plugin.XercesPlugin.getDefault ().getDescriptor().getPluginClassLoader()); Now, a call like: SAXBuilder builder = new SAXBuilder("org.apache.xerces.parsers.SAXParser", validate); should succeed. In this statement, my.xerces.plugin.XercesPlugin is the plugin class that contains the Xerces jars: this plugin must NOT have the Eclipse Xerces plugin in its dependencies! This should also works when Xerces has been installed as an endorsed extension, in this case replace the plugin classloader with the one you ar using: currentThread.setContextClassLoader(this.getClass().getClassLoader()); But this case has not been tested.
Fixed. As of this week's integration build, Eclipse no longer includes a copy of xerces.
