[jira] [Updated] (ODE-924) Incorrect Xpath processing for BPEL 1.1

["tbuss (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ODE-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

tbuss updated ODE-924:
----------------------

    Attachment: src-ODE-922-924.zip

This fix overlap with my proposed fix for ODE-922.  The file, from.java, is modified by both fixes.  I have combined my fix for ODE-922 with my proposed fix for ODE-924 since they are both related to BPEL 1.1 support

> Incorrect Xpath processing for BPEL 1.1
> ---------------------------------------
>
>                 Key: ODE-924
>                 URL: https://issues.apache.org/jira/browse/ODE-924
>             Project: ODE
>          Issue Type: Bug
>          Components: BPEL Compilation/Parsing, BPEL Runtime
>    Affects Versions: 1.3.5
>         Environment: Windows XP SP3, Tomcat-7.0.10, jdk1.6.0
>            Reporter: tbuss
>         Attachments: src-ODE-922-924.zip
>
>
> I am trying to port some BPLE 1.1 workflows to Ode 1.3.5 but I am having difficulty with absolute xpath expressions. For example, the following fails with a selectionFailure fault.
>           <assign name="GetProjects" uuid="41b4d5c8-ff05-406f-ad6d-8f3c816a6521">
>             <copy>
>               <from variable="appAuth" query="/ns8:appAuth" />
>               <to variable="GetProjects-GetProjects" part="parameters" query="/ns8:GetProjects/ns8:auth" />
>             </copy>
>           </assign>
> I am able to work around this issue by changing all the xpaths wherever they are found to relative xpath expressions, omitting the /rootElement/ part of the xpath.  In some case this means omitting the containing attribute entirely.  Here is the same example with the workaround.
>           <assign name=" GetProjects" uuid="41b4d5c8-ff05-406f-ad6d-8f3c816a6521">
>             <copy>
>               <from variable="appAuth"/>
>               <to variable=" GetProjects-GetProjects " part="parameters" query="ns8:auth" />
>             </copy>
>           </assign>
> While resulting BPEL will execute correctly it is a serious impediment to running BPEL 1.1 processes on Ode.
> Also According to the BPEL4WS1.1 spec this behavior is not correct.  Section 14.1 Assignment states that
> "Compliant implementations of the current version of BPEL4WS MUST support the use of XPath 1.0 as the query language"
> and that
> "For XPath 1.0, the value of the query attribute MUST be an absolute locationPath (with '/' meaning the root of the document fragment representing the entire part). It is used to identify the root of a subtree within the document fragment representing the part. The location path MUST select exactly one node. If the location path selects zero nodes or more than one node during execution, then the standard fault bpws:selectionFailure MUST be thrown by a compliant implementation."
> 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 if 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".
> However, Ode 1.3.5 requires the xpath query to be either "ns8:auth" or "/ns8:auth" to successfully select the ns8:auth element, both of which seem odd.
> I have created a proposed fix for this which I will attach.
> The fix 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 an incorrect absolute path like "/ns8:auth" works.  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.
> For the original user mailing list discussion see
> http://mail-archives.apache.org/mod_mbox/ode-user/201105.mbox/%3c1B3A9CAA04782F40AC59576CFBFC802C0B2390140D@VA3DIAXVS251.RED001.local%3e

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira