[jdom-interest] newbie question
laurent.bihanic at atosorigin.com
Wed Dec 4 08:44:44 PST 2002
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).
More information about the jdom-interest