Ok, I've found it. Your part is a type, not an element. And the expression
$request.requestMessageData points to the part itself, any XPath expression
will therefore be evaluated on the nodeset of the part child nodes. So the
full expression should be $request.requestMessageData/requestID, you don't
need to repeat the part name in there as there's no element for it.
On 9/18/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
On 9/18/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> 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.
This modification fixed the problem I was seeing.
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.
I am still having some trouble with this. I have an assign that looks
like...
<copy>
<from>$request.requestMessageData/testMessage/requestID</from>
<to variable="probeInput" part="probeName"/>
</copy>
and the data looks like ...
<requestMessageData><testMessage><requestID>StartTest1.1
</requestID><requestText>EventStartTest1.1</requestText><flowIndicators><indicatorOne>yes</indicatorOne><indicatorTwo>yes</indicatorTwo></flowIndicators><loopIndicator>min</loopIndicator></testMessage></requestMessageData>
At runtime, $request.requestMesageData is successfully resolved to (
<testMessage><requestID>StartTest1.1</requestID><requestText>
EventStartTest1.1</requestText><flowIndicators><indicatorOne>yes</indicatorOne><indicatorTwo>yes</indicatorTwo></flowIndicators><loopIndicator>min</loopIndicator></testMessage>
) as variableNode and variableNode.getChildNodes() is returned. I don't
know why but the evaluation fails with this. If I put back the code that
wraps a a Document around variableNode the evaluation succeeds.
I am thinking it must have something to do with relativePath/absolutePath
but I am not seeing it. I'll check this into the bpel-test project.
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
> >
> >
>
>
