ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave MacLean" <Dave.MacL...@businessobjects.com>
Subject XPath10 expression evaluation and the AsyncProcess2 example - potential fix
Date Thu, 19 Oct 2006 19:06:22 GMT
Hello,
I've been working on getting the AsyncProcess2 example to work under an
axis 2 deployment, and I think I ran into a bug.

The xpath evaluation was failing when trying to evaluate this "from"
line of the first assign in the bpel:

<from
expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">
  count(bpws:getVariableData('Input', 'payload',
'/typ:AllOrders')/typ:Order)
</from>


In particular, it had trouble evaluating the /typ:AllOrders expression.
The actual xml I'm using for the soap message is the one that appears in
subversion for the example, and starts like this:

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Body>
	<AllOrders xmlns="uri:com.bptest.types">
		<Order >
<!-- etc... -->


Tracing into
org.apache.ode.bpel.elang.xpath10.runtime.XPath10ExpressionRuntime, in
the createContext method, the code instantiates a new ContextSupport
with a BpelDocumentNavigator created using: 

new BpelDocumentNavigator(ctx.getRootNode()) 

where ctx is the EvaluationContext passed in.

The problem is the root node returned here points to the AllOrders
element.  That would appear to be ok, but when tracing into the jaxen
evaluation later on, it starts comparisons with the *first child* of the
root node given - That is, the order of the nodes returned by the
AxisNodeIterator used in the jaxen source never returns the root node
itself, just the children and siblings.

This leads to the first comparison being against that first "<Order>"
tag, which causes no matches to occur and an empty array resulting from
the evaluation (when it should match that first "<AllOrders>" tag and
return that one match.  Since I'm assuming the jaxen evaluation code is
correct, it looks like we *need* to have some document wrapping the root
node in this case *or* we need to have the EvaluationContext's root node
returning a "parent" node of the node we're actually interested in...

For example, changing the createContext method to the below did fix the
problem I was having (but I'm worried this exact change may cause other
unexpected behavior):


private Context createContext(OXPath10Expression oxpath,
EvaluationContext ctx) {
    JaxenContexts bpelSupport = new JaxenContexts(oxpath,
_extensionFunctions, ctx);
    Node rootNode = ctx.getRootNode();
    if (rootNode!=null && rootNode.getParentNode()!=null)
    {
    	rootNode = rootNode.getParentNode();
    }
    ContextSupport support = new ContextSupport(new
JaxenNamespaceContextAdapter(oxpath.namespaceCtx),
                                                bpelSupport,
bpelSupport, 
                                                new
BpelDocumentNavigator(rootNode));
    Context jctx = new Context(support);

    if (ctx.getRootNode() != null)
      jctx.setNodeSet(Collections.singletonList(ctx.getRootNode()));

    return jctx;
  }


Basically, it just sets the BpelDocumentNavigator to use the parent node
of the root node returned by the EvaluationContext, if available.  With
this change and a proper deploy.xml file (and a few minor wsdl changes),
the AsyncProcess2 example runs and returns correctly in the Axis2
environment.


Can any one provide guidance on the "proper" way to be doing something
equivalent? 

a) Should the EvaluationContext.getRootNode() method return a wrapping
document/parent node?

Or, 
b) Should we be doing something like I have above, where we pass in the
proper root node when creating the navigator?

Or, 
c) Should the navigator somehow be modified so that it uses the correct
root node when calling the jaxen libraries to find matches to the
expression?


I'm going to attach another thread below that might be related to this
same issue, although it's related to XPath20 and not XPath10.  


Thanks in advance,

Dave







>From "Matthieu Riou" <matthieu.r...@gmail.com> 
Subject Re: XPath 20 
Date Tue, 19 Sep 2006 17:45:38 GMT 

Ok, I've found it. Your part is a type, not an element. And the
expression
$request.requestMessageData points to the part itself, any XPath
expression
will therefore be evaluated on the nodeset of the part child nodes. So
the
full expression should be $request.requestMessageData/requestID, you
don't
need to repeat the part name in there as there's no element for it.

On 9/18/06, Lance Waterman <lance.waterman@gmail.com> wrote:
>
>
>
> On 9/18/06, Matthieu Riou <matthieu.riou@gmail.com> wrote:
>
> > Hi Lance,
> >
> > See my comments inline...
> >
> > 1) XPath20ExpressionRuntime ( line 173 )
> > >
> > >             Object evalResult =
expr.evaluate(DOMUtils.newDocument(),
> > > type);
> > >
> > > Does this imply that all xpath syntax must contain a variable
> > reference?
> >
> >
> > I don't believe so. The DOMUtils.newDocument() is the context node
on
> > which
> > the expression applies. For all BPEL expressions there's no context
> > node,
> > that's why I'm passing an empty document. I've recently modified
this to
> >
> > provide a context node for the evaluation of correlation property
alias,
> > the
> > only case in BPEL when a context node is required.
>
>
> This modification fixed the problem I was seeing.
>
> The type is the return type you'd like the XPath processor to return.
> > Basically a nodeset, a node, a number or a string.
> >
> > Finally the returned object is usually a nodeset. But it can contain
a
> > simple TextNode with a number in it for example. So there's nothing
here
> >
> > forcing an xpath expression to contain a variable. The
> > XPathVariableResolver
> > will just never be called.
> >
> > 2) It looks like you recently checked in a change to
> > JaxpVariableResolver
> > > that removed the following ...
> > >
> > >                 // Saxon expects a nodelist, everything else will
> > result
> > > in
> > > a wrong result...
> > >                 Document doc = DOMUtils.newDocument();
> > >                 doc.appendChild (doc.importNode(variableNode,
true));
> > >                 return doc.getChildNodes();
> > >
> > > for
> > >
> > >                 return variableNode.getChildNodes();
> >
> >
> > Yes, this is the right behaviour. I used to return the variable node
> > itself
> > (wrapped in a document) instead of its children. However if you have
an
> > expression like $var/name and your XML node looks like
> > <variable><name>joe</name></variable>, you must return the
children
> > nodeset
> > (name) to get any result. If you return the whole variable element,
the
> > only
> > working expression will be $var/variable/name which isn't proper
BPEL.
>
>
> I am still having some trouble with this. I have an assign that looks
> like...
>
>                     <copy>
>
> <from>$request.requestMessageData/testMessage/requestID</from>
>                         <to variable="probeInput" part="probeName"/>
>                     </copy>
>
> and the data looks like ...
>
> <requestMessageData><testMessage><requestID>StartTest1.1
>
</requestID><requestText>EventStartTest1.1</requestText><flowIndicators>
<indicatorOne>yes</indicatorOne><indicatorTwo>yes</indicatorTwo></flowIn
dicators><loopIndicator>min</loopIndicator></testMessage></requestMessag
eData>
>
>
> At runtime, $request.requestMesageData is successfully resolved to (
> <testMessage><requestID>StartTest1.1</requestID><requestText>
>
EventStartTest1.1</requestText><flowIndicators><indicatorOne>yes</indica
torOne><indicatorTwo>yes</indicatorTwo></flowIndicators><loopIndicator>m
in</loopIndicator></testMessage>
> ) as variableNode and variableNode.getChildNodes() is returned. I
don't
> know why but the evaluation fails with this. If I put back the code
that
> wraps a a Document around variableNode the evaluation succeeds.
>
> I am thinking it must have something to do with
relativePath/absolutePath
> but I am not seeing it. I'll check this into the bpel-test project.
>
>
> not sure why but this has caused my unit test to break. I can dig into
> > this
> > > more but I just wanted to ping you first.
> >
> >
> > If it helps, you could commit your tests and if you tell me how to
try
> > them
> > out, I can have a look as well. There might be some edge cases that
I
> > didn't
> > properly handled.
> >
> > Matthieu
> >
> > Thanks for your help,
> > >
> > > Lance
> > >
> > >
> >
> >
>



Mime
View raw message