<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
On 01/20/2012 05:56 AM, Rolf Lear wrote:
<blockquote cite="mid:779b646e68bc8d6f49267a572345c616@tuis.net"
type="cite"> <font size="2">2. new JDOM2 XPathFactory concept
which can have different implementation</font><font size="2">
back-ends (Jaxen, Saxon, whatever).</font>
<br>
</blockquote>
+1<br>
<blockquote cite="mid:779b646e68bc8d6f49267a572345c616@tuis.net"
type="cite">
<p><font size="2">3. XPathFactories are thread-safe and reusable
in any threads.</font>
<br>
</p>
</blockquote>
+1<br>
<blockquote cite="mid:779b646e68bc8d6f49267a572345c616@tuis.net"
type="cite">
<p><font size="2">4. have a single 'default' XPathFactory instance
obtainable with</font>
<br>
<font size="2">XPathFactory.instance(). The default back-end
instance() can be changed</font>
<br>
<font size="2">with a system property.</font>
<br>
</p>
</blockquote>
This is causing me trouble at the moment. I have to override the
XPathFactory, to provide common function definitions and to avoid
performance problems that Java classlibrary and JAXP cause. In
JDOM1 I do this in a static class:<br>
<tt>public class JDOMUtil {<br>
static {<br>
try {<br>
XPath.setXPathClass(JaxenXPath.class);<br>
} catch (JDOMException e) {<br>
throw new RuntimeException(e);<br>
}<br>
}<br>
</tt><br>
I can be assured that it works, and though I'm not sure under what
conditions it throws a checked exception, if it does throw one, it's
a system startup failure to be debugged by a system engineer.<br>
<br>
With JDOM 2 alpha I have to do this<br>
<br>
<tt>// replaced with
-Dorg.jdom2.xpath.XPathFactory=com.example.jaxen.JaxenXPath<br>
static {<br>
if
(!(JaxenXPath.class.getName().equals(System.getProperty(JDOMConstants.JDOM2_PROPERTY_XPATH_FACTORY))))
{<br>
throw new RuntimeException(String.format("JDOM Not set up
property with -D%=%", JDOMConstants.JDOM2_PROPERTY_XPATH_FACTORY,<br>
JaxenXPath.class.getName()));<br>
}<br>
}<br>
<br>
</tt>Now I've got JDOM2 dependencies off in a faraway place of Java
CLI, where they can easily get lost.<br>
<blockquote type="cite"><font size="2">6. Other back-ends can be
used at will by calling the</font>
<br>
<font size="2">XPathFactory.newInstance(String) method (or some
direct constructor on the</font>
<br>
<font size="2">Factory if it exposes one).</font>
</blockquote>
This doesn't help me fix the above problem, because all of the
ThreadLocal cache logic and pretty entrypoints into the XPath class
itself are hardwired to use the System-property defined
constructor. So they might as well not be there.<br>
<br>
<blockquote cite="mid:779b646e68bc8d6f49267a572345c616@tuis.net"
type="cite">
<p><font size="2">5. the default 'default' back-end will continue
to be Jaxen</font>
<br>
</p>
</blockquote>
<br>
Personally, I'd prefer it if you broke this requirement up into a
few parts and made it easy to have a Jaxen backend.<br>
For example, you might say that there's no XPath support without
also loading jdom2.jar and jdom2-jaxen.jar.<br>
Right now, with Jaxen having JDOM1 support built in, and then JDOM2
having Jaxen support built in, it causes a bit of circular confusion
trying to get things to work.<br>
<br>
If we could configure JDOM to use Saxon and have it get good
performance without unnecessary recalculations, we'd not even load
Jaxen all.<br>
<br>
Leigh.<br>
<br>
<br>
</body>
</html>