Hi Matthieu, Thanks for the very quick and helpful reply. I updated the bpel to use the proper variable selection in all places (and removed my "fixes" from my local source), and got the sample mostly running (ran into another unrelated issue, but after commenting out a small section I had the test running).
Would it be worth checking in a fixed up version of this example now that it's ported over and cleaned up (after I get the other small issue worked out)? Either way, thanks for your help! -Dave -----Original Message----- From: Matthieu Riou [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 2:55 PM To: [email protected] Subject: Re: XPath10 expression evaluation and the AsyncProcess2 example - potential fix Hi Dave, So if you're doing BPEL 2.0 actually you shouldn't use getVariableData but the new $message.part notation. That's so much easier to use and the getVariableData function is deprecated (understand has been removed from the spec) in 2.0. For the examples, you should check the axis2-examples module (or the jbi-examples module for JBI) as the examples module is rather outdated. Nothing in there will work. We kept it to migrate all examples little by little but I think it's rather misleading so I'll probably remove it soon. The easiest way to start with something clean is to use the distribution produced in distro-axis2/target. As for what the getVariableData returns, I think it's the right behavior. The main reason is WS-BPEL 2.0 compatibility. The $message.part notation in WS-BPEL 2.0 is specified as returning the part content and not the part element itself. The BPEL4WS spec isn't really specific about it, it was sort of left on the side. So to be coherent it makes more sense to have the same behavior on getVariableData than on $message.part. So the bad thing here is only the XPath expression used in the example. It's simply wrong. Hope this helps, Matthieu On 10/19/06, Dave MacLean <[EMAIL PROTECTED]> wrote: > > 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? > > > > > > > > > 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 > > > > > > > > > > > > > > > > >
