[jdom-interest] newbie question

bob mcwhirter bob at werken.com
Wed Dec 4 09:27:43 PST 2002

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

I can understand needing dynamically resolvable VariableContext, but you
have namespace prefix->uri bindings that change between invocations?
The NamespaceContext really should be considered (or at least I consider
it) to be a static member of the XPath itself, and not really settable

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

I'm imagining this:

  xpath.selectNodes(Object contextNode, VariableContext varContext);

So, in this case, you pass your own magical VariableContext into
the evaluation.  You can consider the VariableContext to be your
applicate object.  You just have to implement the VariableContext
interface on whatever object you care to pass around.

public class MyVarCtx implements VariableContext
  MyVarCtx(MySpecialStuff stuff)


  public Object getVariableValue(String uri, String prefix, String localName)
    return getMySpecialStuff().doWhatever( uri, localName );

The getVariableValue(..) on your VariableContext implementation is
the special application-object context you wanted, and you have access
to anything else in your implementation.  

Plus, it keeps it uncomplicated for folks who just want to
parameterize and pass in a SimpleVariableContext with each
execution.  Or maybe just wrap their own HttpServletRequestVariableContext
to make any query-arg available in evaluated xpaths.

The fact that VariableContext is just a simple 1-method interface,
instead of an abstract class really opens up what you can do
while keeping jaxen's own logic and API simpler.


More information about the jdom-interest mailing list