Merge branch 'xml-woes'

This topic branch adds a rather ugly, but required, work-around when
3rd-party libraries provide XML components that can easily lead to
class path problems when processing XML data via XPath. The symptom
is invariable an exception with a trace like this one:

> java.lang.NoSuchMethodError: org.apache.xpath.XPathContext.<init>(Z)V
>	at org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207)
>	at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281)
>	at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:371)
>	at org.scijava.util.XML.<init>(XML.java:141)
>	[...]

Such errors are caused by whatever implementation of the XPathFactory
finds to be claiming the DocumentBuilderFactoryImpl service in the
corresponding META-INF/services/.

For example, the Batik component in Fiji ships a part of xalan (which is
actually not needed for Java 1.6 and later, because Xalan is now bundled
with Java), and likewise does OMERO insight ship xalan, but an
*incompatible* version of it.

As a work-around, we use the fact that the XPathFactory asks the current
thread's context class loader to discover the services. If it discovers
a non-functional XPath implementation, we set the context class loader
to the parent class loader until we find a working XPath implementation.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Author: dscho

src/main/java/org/scijava/util/XML.java

@@ -76,6 +76,9 @@ public class XML {
 	/** XPath evaluation mechanism. */
 	private final XPath xpath;
 
+	private final boolean debug =
+			"debug".equals(System.getProperty("scijava.log.level"));
+
 	/** Parses XML from the given file. */
 	public XML(final File file) throws ParserConfigurationException,
 		SAXException, IOException
@@ -113,7 +116,51 @@ public XML(final Document doc) {
 	public XML(final String path, final Document doc) {
 		this.path = path;
 		this.doc = doc;
-		xpath = XPathFactory.newInstance().newXPath();
+
+		// Protect against class skew: some ImageJ projects find it funny to ship
+		// outdated xalan, sometimes causing problems due to incompatible
+		// xalan/xerces combinations.
+		// 
+		// We work around that by letting the XPathFactory try with the current
+		// context class loader, and fall back onto its parent until it succeeds
+		// (because the XPathFactory will ask the context class loader to find the
+		// configured services, including the
+		// com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl).
+		if (debug) {
+			System.err.println(ClassUtils.getLocation(XPathFactory.class));
+		}
+
+		XPath xpath = null;
+		final Thread thread = Thread.currentThread();
+		final ClassLoader contextClassLoader = thread.getContextClassLoader();
+		try {
+			ClassLoader loader = contextClassLoader;
+			for (;;) try {
+				xpath = XPathFactory.newInstance().newXPath();
+				try {
+					// make sure that the current xalan/xerces pair can evaluate
+					// expressions (i.e. *not* throw NoSuchMethodErrors).
+					xpath.evaluate("//dummy", doc);
+				} catch (Throwable t) {
+					if (debug) {
+						System.err.println("There was a problem with " +
+							xpath.getClass() + " in " +
+							ClassUtils.getLocation(xpath.getClass()) + ":");
+						t.printStackTrace();
+					}
+					throw new Error(t);
+				}
+				break;
+			} catch (Error e) {
+				if (debug) e.printStackTrace();
+				loader = loader.getParent();
+				if (loader == null) throw e;
+				thread.setContextClassLoader(loader);
+			}
+			this.xpath = xpath;
+		} finally {
+			thread.setContextClassLoader(contextClassLoader);
+		}
 	}
 
 	// -- XML methods --