ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Buss <TB...@SERENA.com>
Subject RE: Problem with BPEL 1.1 Xpath support
Date Wed, 08 Jun 2011 20:20:58 GMT
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.


-----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.

View raw message