[jdom-interest] newbie question

[bob mcwhirter]

> > Also, fwiw, I've got changes in the pipe-line, so that when evaluating
> > the XPath, you can pass a VariableContext into the method, allowing for
> > multi-threadsafe evaluation of an XPath with simultaneous different
> > variable bindings.  Not in jaxen yet, but soon.  Was just an oversight.
> 
> This is a general problem: To reuse compiled XPaths in a multi-threaded 
> application you need to pass per-thread context information to XxxContext 
> implementations (VariableContext, NamespaceContext...).
> But this context information is very often application-specific and thus out 
> of Jaxen scope. So, passing a VariableContext to the methods may only apply to 
> few specific cases.

Over on the jaxen-interest list, we were talking about this, and figured
that really NamespaceContext and FunctionContext probably don't need to
be customized by each thread.  The VariableContext, on the other hand,
might include things like $username and other such thread-specific information.

> A more general solution would be to provide overloaded mehods allowing the 
> application to pass a "call context" object (java.lang.Object) and to enhance 
> the XxxContext interfaces to add 2 arguments: the context object the XPath 
> expression is being evaluated on and the application "call context".
> 
> You may have a look at the latest implementation of JDOM Jaxen-wrapper 
> (org.jdom.xpath.JaxenXPath.java) to see the trick required to pass context 
> information to a NamespaceContext. And it does not even support 
> multi-threading! In a multi-threaded environment, one would have to replace 
> the currentContext object by a Hashtable, using Thread.currentThread() as key.

At least with core jaxen, there's no state within the XPath itself, and
all the context stuff is passed around with a ContextSupport and such,
so I don't see the need for maintaining a ThreadLocal or anything.

Maybe I'm missing something?

	-bob