[
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
