Matthieu,
Thanks, that makes sense and it helps to have another pair of eyes. A couple
of questions. I think I was getting confused because I had been working with
the propertyAlias syntax:
<bpws:propertyAlias propertyName="tns:testProbeData"
messageType="tns:requestMessage" part="requestMessageData">
<bpws:query queryLanguage="urn:oasis:names:tc:wsbpel:
2.0:sublang:xpath2.0">
testMessage/requestText
</bpws:query>
</bpws:propertyAlias>/>
Were it appears that the "testMessage" is a required query node. I think it
is because XPath20ExpressionRuntime.evaluate() [line 177] ...
Object evalResult = expr.evaluate(ctx.getRootNode() == null ?
DOMUtils.newDocument() : ctx.getRootNode(), type);
The root node appears to have the part name in it ( even though the
propertyAlias has specified the part attribute ). Should this behave similar
to the $request.requestMessageData/requestText syntax?
Lance
On 9/19/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
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
> > >
> > >
> >
> >
>
