[jdom-interest] newbie question

[Laurent Bihanic]

bob mcwhirter wrote:
> 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.

You may have a look at Jato's org.jato.xpath.JaxenXPath wrapper (see Jato 
project at http://sourceforge.net/projects/jato) for examples of 
thread-specific NamespaceContext and VariableContext implementations.

>>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".
> 
> 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.

I haven't considered ThreadLocals. The problem I'm trying to solve is using 
compiled XPaths in a multi-threaded environment: I can only assign one 
NamespaceContext and one VariableContext per XPath object but my 
implementations of NamespaceContext and VariableContext need a way to retrieve 
per-call context information.
In this context, the simplest solution (for me!) would be for Jaxen to allow 
me to pass an application object to selectNodes() that would be made available 
to NamespaceContext and VariableContext (or any other context).

Laurent