[ http://issues.apache.org/jira/browse/ODE-71?page=all ]
Dave MacLean updated ODE-71:
----------------------------
Attachment: AsyncProcess2.zip
Ported the AsyncProcess2 example to work with the axis 2 war deployment. See
the bug comments for possible fix suggestions that make this test run correctly.
To run, unzip to a AsyncProcess2 folder in your processes directory.
Then, using the command line run:
sendsoap http://localhost:8080/ode/processes/AsyncProcess2/Invoke message.soap
When successful, you should see a list of orders returned.
> AsyncProcess2 test ported to Axis2 deployment not functioning properly do to
> an error when evaluating the XPath10 expression
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: ODE-71
> URL: http://issues.apache.org/jira/browse/ODE-71
> Project: Apache Ode
> Issue Type: Bug
> Components: BPEL Runtime, BPEL Compilation/Parsing
> Affects Versions: Incubator
> Environment: win32_x86, windows xp, Tomcat with ode's generated axis2
> war, debugging with Eclipse dev environment
> Reporter: Dave MacLean
> 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:[EMAIL PROTECTED]
> Sent: Thursday, October 19, 2006 12:06 PM
> To: [email protected]
> 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" <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On 9/18/06, Matthieu Riou <[EMAIL PROTECTED]> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
