Hi Lance,
See my comments inline...
1) XPath20ExpressionRuntime ( line 173 )
Object evalResult = expr.evaluate(DOMUtils.newDocument(),
type);
Does this imply that all xpath syntax must contain a variable reference?
I don't believe so. The DOMUtils.newDocument() is the context node on which
the expression applies. For all BPEL expressions there's no context node,
that's why I'm passing an empty document. I've recently modified this to
provide a context node for the evaluation of correlation property alias, the
only case in BPEL when a context node is required.
The type is the return type you'd like the XPath processor to return.
Basically a nodeset, a node, a number or a string.
Finally the returned object is usually a nodeset. But it can contain a
simple TextNode with a number in it for example. So there's nothing here
forcing an xpath expression to contain a variable. The XPathVariableResolver
will just never be called.
2) It looks like you recently checked in a change to JaxpVariableResolver
that removed the following ...
// Saxon expects a nodelist, everything else will result
in
a wrong result...
Document doc = DOMUtils.newDocument();
doc.appendChild(doc.importNode(variableNode, true));
return doc.getChildNodes();
for
return variableNode.getChildNodes();
Yes, this is the right behaviour. I used to return the variable node itself
(wrapped in a document) instead of its children. However if you have an
expression like $var/name and your XML node looks like
<variable><name>joe</name></variable>, you must return the children nodeset
(name) to get any result. If you return the whole variable element, the only
working expression will be $var/variable/name which isn't proper BPEL.
not sure why but this has caused my unit test to break. I can dig into this
more but I just wanted to ping you first.
If it helps, you could commit your tests and if you tell me how to try them
out, I can have a look as well. There might be some edge cases that I didn't
properly handled.
Matthieu
Thanks for your help,
Lance
