=== Description of problem: According to the XPath specification, we have to use XPath with prefixes to search elements with namespaces. Example: The XPath expression //person/name should NOT match any element in the following example but in some XPath implementations it does. <person xmlns="xxx"> <name>Martin</name> </person> JBoss EAP (6.3.0.GA) XPathFactory.newInstance() =>_redirected._XPathFactory But internally is used default JDK XPathFactory implementation => org.apache.xpath.jaxp.XPathFactoryImpl. This implementation does NOT work properly. JBoss Fuse (jboss-fuse-6.1.0.redhat-379) XPathFactory.newInstance() =>net.sf.saxon.xpath.XPathFactoryImpl This implementation does works properly. Switchyard XPath operation selector works differently on both containers. https://github.com/jboss-switchyard/components/blob/2.0.0.Alpha3/common/common/src/main/java/org/switchyard/component/common/selector/BaseOperationSelector.java Some quickstarts are affected e.g. jca-inflow-activemq https://github.com/jboss-switchyard/quickstarts/blob/2.0.0.Alpha3/jca-inflow-activemq/src/main/resources/META-INF/switchyard.xml#L22 https://github.com/jboss-switchyard/quickstarts/blob/2.0.0.Alpha3/jca-inflow-activemq/src/test/java/org/switchyard/quickstarts/jca/inflow/JCAInflowBindingTest.java#L124 === Version-Release number of selected component (if applicable): FSW 6.1 DR2 === How reproducible: 100% === Actual results: SWITCHYARD034503: No node has been matched with the XPath expression '//person/language' in the payload. It couldn't determine the operation. at org.switchyard.component.common.selector.BaseOperationSelector.xpathMatch(BaseOperationSelector.java:121)[349:org.switchyard.components.switchyard-component-common:2.0.0.Alpha2-redhat-1] at org.switchyard.component.common.selector.BaseOperationSelector.selectOperation(BaseOperationSelector.java:66)[349:org.switchyard.components.switchyard-component-common:2.0.0.Alpha2-redhat-1] at org.switchyard.component.http.InboundHandler.getOperationName(InboundHandler.java:150)[353:org.switchyard.components.switchyard-component-http:2.0.0.Alpha2-redhat-1] at org.switchyard.component.http.InboundHandler.invoke(InboundHandler.java:107)[353:org.switchyard.components.switchyard-component-http:2.0.0.Alpha2-redhat-1] at org.switchyard.component.http.HttpGatewayServlet.handle(HttpGatewayServlet.java:159)[353:org.switchyard.components.switchyard-component-http:2.0.0.Alpha2-redhat-1] at org.switchyard.component.http.HttpGatewayServlet.service(HttpGatewayServlet.java:124)[353:org.switchyard.components.switchyard-component-http:2.0.0.Alpha2-redhat-1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0]
Need to determine whether or not this behavior changed from EAP 6.1 to 6.3.
The behavior did not change from EAP 6.1 to 6.3.
Resetting the flags back to the state it was before Oct-24- 2PM. There was an incorrect bulk update that I'm trying to fix.
If the Apache XPath implementation doesn't follow the spec, shouldn't we be filing issues against them?
Should be in first 6.2.1 build.