Bug #5725
closedXPathException thrown and caught when DOM4J not on classpath
0%
Description
A user reports (by email) that XPathExceptions are being silently thrown and caught when DOM4J is not on the classpath. This was picked up using a tool called DynaTrace.
It's a bit of a tricky one to investigate - hard to reproduce in the IDE because if we take DOM4J off the classpath, the build will fail. We could perhaps do a diagnostic build in which all calls to new XPathException()
are logged.
Updated by Michael Kay about 2 years ago
I've added some tracing and I'm seeing
Loader.getClass() org.jdom2.Document
XPath exception created: net.sf.saxon.trans.XPathException.<init> from net.sf.saxon.trans.DynamicLoader.getClass from net.sf.saxon.Configuration.getClass
Loader.getClass() org.dom4j.Document
XPath exception created: net.sf.saxon.trans.XPathException.<init> from net.sf.saxon.trans.DynamicLoader.getClass from net.sf.saxon.Configuration.getClass
The code is trying to determine whether JDOM2 and DOM4J are on the classpath by loading relevant classes. I don't think there is any way to do this without throwing and catching an exception. However, wrapping that exception in an XPathException seems unnecessary. And do we really need to know in advance whether JDOM2 and DOM4J are available? Could we arrange things instead so the failure only occurs if they are actually used?
Updated by Michael Kay about 2 years ago
I'm puzzled that the trace doesn't also show calls for the Axiom and XOM object models - I see those calls when running in the debugger.
Updated by Michael Kay about 2 years ago
Should add org.w3.dom.Document
and com.saxonica.ee.domino.DominoNode
to knownClasses
to avoid the dynamic load.
Updated by Michael Kay about 2 years ago
The mechanism for registering object models by seeing what can be loaded is used for two purposes:
(a) for the JAXP XPath API, to decide whether newInstance() should work for a given object model URI. (In practice, this mechanism is probably used only by Saxon - most JAXP implementations probably work only with DOM).
(b) in various APIs (e.g when handling the result of a reflexive extension function call) we're presented with an object of a given class, and we need to know which object model (if any) can handle objects of this class. We will obviously never be presented with a class that isn't on the class path. So perhaps we should build in the mapping from class names (or package names) in known object models to the Saxon support module and only do the dynamic loading when the need arises? We still need the registration mechanism to support third-party plugins for object models that Saxon doesn't support natively, but we don't need to use this for the built-in models such as DOM4J and JDOM2.
(But is it worth the trouble...?)
Updated by Michael Kay about 2 years ago
- Category set to Build and release
- Status changed from New to Resolved
- Priority changed from Low to Normal
- Applies to branch trunk added
- Fix Committed on Branch trunk added
I've changed the logic for registerExternalObjectModel() so it no longer attempts to load the classes supporting the model in question. This seems to have no adverse effects.
It's slightly risky - there may be configurations that don't work, or error conditions that aren't diagnosed well; but for the moment it seems like a good change. I'll confine it to 12.x for safety.
Updated by Community Admin almost 2 years ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 12.0 added
Bug issue fixed in the Saxon 12.0 Major release
Please register to edit this issue