RE: Problem with BPEL 1.1 Xpath support

[Tim Buss <TB...@SERENA.com>]

I will submit a JIRA for this.  I have a proposed fix which removes any preceding absolute root from the xpath expression in the BPEL 1.1 compiler producing a working compiled version.  

I tried to fix it in the runtime but it is more complex there because of where the ode runtime sets the document root for the temporary document it uses to evaluate the xpath.  This is probably why "/ns8:auth" works btw  (see my description in my previous email).  This makes the handling the cases for both Document Literal and RPC literal difficult because the document root would have be adjusted to different places depending on the case and detecting which case is not trivial to determine by the time we get to the runtime.  Also fixing it at runtime has a chance of destabilizing the BPEL 2.0 runtime which would be bad.

The compiler fix turned out to be fairly elegant for what is essentially a hack.  By just providing the class Expression11 with a pseudo Factory method and replacing all the calls to Expression11 constructor with the factory method call I was able to centralize stripping of the absolute root converting say, "/ns8:GetProjects/ns8:auth", to "ns8:auth",  and also handle the degenerative case of setting a location like this  "/ns8:GetProjects" to null.  The fix is simplistic;  I'm not parsing the xpath or attempting to deal with all cases so there may be expressions that don't work. 

More testing is required but the fix seems to work for all the cases I have tried including queries nested in GetVariableData functions so I will attach it to the JIRA.  I believe it is specific to BPEL 1.1 and should have no effect on BPLE 2.0 processes.  It may break any BPEL 1.1 processes that were written to work around this issue.  I suspect existing relative paths will still work since I am only looking for absolute expressions and let relative expressions through. However, an incorrect absolute path like the "/ns8:auth" example I gave will get stripped out and won't produce the correct result at runtime as it does now.

Tim

-----Original Message-----
From: Tim Buss 
Sent: Tuesday, May 24, 2011 6:58 PM
To: 'user@ode.apache.org'
Subject: RE: Problem with BPEL 1.1 Xpath support

A further clarification.

As best I can tell, and the documentation on this is rather sparse, the locationPath query for BPEL4WS 1.1 should either be rooted on the part name if the part is defined using a type (typical for RPC literal style wsdls) or of the part name is defined using an element (typical for document literal wsdls) then the element name should be used.  In the example I gave, the service is document literal and the element name that defines the part in the wsdl is ns8:GetProjects.   Hence it seems the required Xpath query should be "/ns8:GetProjects/ns8:auth".  If the service had been rpc literal then the required xpath should be "parameters/ns8:auth" since the part is named "parameters".

On debugging it seems that Ode 1.3.5 creates a variable the represents the part that appears to be in a document message/parameters/ns8:GetProjects.  However,  Ode the requires  the xpath query to be either "ns8:auth" or "/ns8:auth" to successfully select the ns8:auth element, both of which seem odd.

Regards,
Tim