ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ODE-71) AsyncProcess2 test ported to Axis2 deployment not functioning properly do to an error when evaluating the XPath10 expression
Date Thu, 09 Aug 2007 17:35:44 GMT

     [ https://issues.apache.org/jira/browse/ODE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Matthieu Riou updated ODE-71:
-----------------------------

        Fix Version/s: 1.1
    Affects Version/s:     (was: Incubator)
                       1.0-incubating

> AsyncProcess2 test ported to Axis2 deployment not functioning properly do to an error
when evaluating the XPath10 expression
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ODE-71
>                 URL: https://issues.apache.org/jira/browse/ODE-71
>             Project: ODE
>          Issue Type: Bug
>          Components: BPEL Compilation/Parsing, BPEL Runtime
>    Affects Versions: 1.0-incubating
>         Environment: win32_x86, windows xp, Tomcat with ode's generated axis2 war, debugging
with Eclipse dev environment
>            Reporter: Dave MacLean
>             Fix For: 1.1
>
>         Attachments: AsyncProcess2.zip
>
>
> (Pasting post from mailing list, will attach unit test in a zip)
> Following up, I think a more correct change would be to pursue what I listed as "a)"
below:
> In org.apache.ode.bpel.engine.BpelRuntimeContextImpl, under the method "getPartData",
we currently have the code:
> public Node getPartData(Element message, Part part) {
>     Element partEl = DOMUtils.findChildByName(
> 					(Element) message, 
> 					new QName(null, part.name), 
> 					false);
>     if (partEl == null)
>         return null;
>     Node container = DOMUtils.getFirstChildElement(partEl);
>     if (container == null)
>         container = partEl.getFirstChild(); // either a text node / element
>     return container;
> }
> This seems incorrect.  Shouldn't part data return the actual part and not the part's
first child?  
> I would propose to change this to:
> public Node getPartData(Element message, Part part) {
>     return DOMUtils.findChildByName(
> 					(Element) message, 
> 					new QName(null, part.name), 
> 					false);
> }
> For a wsdl that contains a message like this:
> 	<message name="ProcessInputMessage">
> 		<part name="payload" element="typ:AllOrders"/>
> 	</message>
> The dom-parsed xml structure ends up looking like:
> <?xml version="1.0" encoding="UTF-8"?>
> <message>
> <payload>
>     <AllOrders xmlns="uri:com.bptest.types">
> 		<Order>
> 			<OrderId>1161286397524-1</OrderId>
> 			<OrderType>BookOrder</OrderType>
> 			<!-- etc... -->
> The current version of the method getPartData method returns the "AllOrders" tag, the
proposed version would return the "payload" tag.
> Does this make sense?  With this change, the xpath evaluation works correctly, since
when the XPath10 libaries start their evaluation of "/typ:AllOrders" on the first child of
"payload", it matches "AllOrders"
> correctly.
> I guess it just makes more sense that "getPartData" would actually get the part instead
of getting the part's first child...
> Any comments on this?
> Thanks,
> Dave
> -----Original Message-----
> From: Dave MacLean [mailto:Dave.MacLean@businessobjects.com]
> Sent: Thursday, October 19, 2006 12:06 PM
> To: ode-dev@incubator.apache.org
> Subject: XPath10 expression evaluation and the AsyncProcess2 example - potential fix
> 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?
> > >
> > >
> >

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message