Moddy Te'eni wrote:
I'm trying to write a server that uses XPath API. I based my code around the
sample 'SimpleXPathAPI'. I have many questions.
My server receives messages with documents, and returns the results of a few
XPath expressions on these documents. the expressions can be updated while
running. There are some external functions, and some varirables that i added
to XPathExecutionContextDefault (following dave's advice
http://www.nabble.com/creating-variables-for-XPath-td21823462.html)
1. Can I use an XPath after its XPathConstructionContext is deleted? if not,
can i use one global XPathConstructionContext to construct all my XPath
objects?
No. You can use a global XPathConstructionContext, but you will need to
serialize access to it if you are using multiple threads. If you do
this, you cannot destroy any XPath instances you've constructed with
until you can destroy them all. It works this way so that in situations
where there are lots of XPath instances, such as in an XSLT stylesheet,
common resources are shared.
2. What is the difference between XPathProcessor::initXPath and
XPathProcessor::initMatchPattern ?
One creates an XPath instance from an XPath expression, and the other
creates an XPath instance from a match pattern, which is a limited
subset of XPath. Match patterns are described here:
http://www.w3.org/TR/xslt#patterns
These should really be separate classes, but the history is complicated,
and it would be somewhat difficult to separate out the two classes at
this point.
It's unlikely you would be interested in match patterns, since they are
designed to determine whether or not a node matches the pattern, rather
than to find what nodes match a particular XPath expression.
3. Why does XPathEvaluator::evaluate calls reset() for its executionContext
and XObjectFactory, and why does it sets the executionContext's EnvSupport,
DOMSupport and XObjectFactory? What happens if I set it only once?
(assuming there is one evaluator for each input document)
It resets these for various reasons:
1. It resets the XPathExecutionContext and the XPathEnvSupport instance
because it doesn't make sense for state from one evaluation to leak into
another one.
2. It resets the XObjectFactory to prevent a large number of XObject
instances from accumulating. You can certainly change this if you want
to. For example, you might want to reset only after a certain number of
XPath expressions have been evaluated. This would mean you could keep a
number of evaluation results around between evaluations. The current
model forces the user to copy the result of the evaluation before
evaluating another expression.
3. You can ignore DOMSupport::reset() as it is only there for
backward-compatibility. It's a no-op in the current version.
4. Can I have one global XPathProcessorImpl?
As long as you serialize access to it and any other objects it uses that
are not thread-safe.
Most objects in Xalan-C are not thread safe. The ones that are, such as
instances of the the source tree, and XPaths are thread-safe, because
they keep state in the other objects (such as XPathExecutionContext,
XPathEnvSupport, etc.). This allows sharing these "heavier" objects
between threads.
Dave
