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
