Re: suggested JDOM2 improvements

On 01/20/2012 12:28 PM, Rolf Lear wrote:
>
> On the other hand, because XPathFactory instances are specified to be
> thread-safe, there is nothing stopping you from doing:
>
> public static final XPathFactory XPATH =
> XPathFactory.newInstance("com.example.xpath20.XPathFactory");
>
> Then in your code you can freely use:
>
> XPathCompiled<Object> xp = XPATH.compile("//*");
>
> ...
>
> The best practice would be for you to get your own instance of your own
> factory, then use that instance from wherever you need it.
>
>

I'd like to use a custom factory as you describe above, but right now, 
that makes all public methods on org.jdom2.xpath.XPath useless, because 
they use a static threadlocal factory which can only be the result of 
XPathFactory.newInstance(), which is the DEFAULTFACTORY from 
XPathFactory, which is settable only by the System property:

public abstract class XPath {

     private static final ThreadLocal<XPathFactory> localfactory =
             new ThreadLocal<XPathFactory>();

     public static List<?> selectNodes(final Object context, final 
String path)
             throws JDOMException {
         return newInstance(path).selectNodes(context);
     }

     public static final XPath newInstance(final String path) throws 
JDOMException {
         XPathFactory fac = localfactory.get();
         if (fac == null) {
             fac = XPathFactory.newInstance();
             localfactory.set(fac);
         }
         return fac.compile(path);
     }
}

The reason I use a custom factory is to work around a performance 
problem with Jaxen: 
org.jaxen.saxpath.helpers.XPathReaderFactory.createReader() does an 
expensive synchronized System.getProperty() that causes concurrency 
bottlenecks, and it's done frequently, and there's no way to configure 
Jaxen or JDOM to use a specific implementation class rather than consult 
System.getProperty every time.

To fix this, I have to split apart a whole stack of factory code from 
JDOM and Jaxen, just in order to get at the createReader() method.

Another reason to use a custom XPath factory would be to use the JDOM 
API for XPath to get the work done with Saxon.

So, to summarize, my complaint is that if I want to use a custom XPath 
factory for whatever reason (and I've given two above), I cannot use any 
of the XPath public static methods.

Leigh.

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]