ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "tbuss (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ODE-924) Incorrect Xpath processing for BPEL 1.1
Date Wed, 08 Jun 2011 21:01:59 GMT
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


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

Mime
View raw message