...
Code Block |
---|
XPathBuilder INFO Using system property javax.xml.xpath.XPathFactory:http://saxon.sf.net/jaxp/xpath/om with value: net.sf.saxon.xpath.XPathFactoryImpl when creating XPathFactory |
Enabling Saxon from Spring DSL
Available as of Camel 2.10
Similarly to Java DSL, to enable Saxon from Spring DSL you have three options:
Specifying the factory
Code Block | ||||
---|---|---|---|---|
| ||||
<xpath factoryRef="saxonFactory" resultType="java.lang.String">current-dateTime()</xpath>
|
Specifying the object model
Code Block | ||||
---|---|---|---|---|
| ||||
<xpath objectModel="http://saxon.sf.net/jaxp/xpath/om" resultType="java.lang.String">current-dateTime()</xpath>
|
Shortcut
Code Block | ||||
---|---|---|---|---|
| ||||
<xpath saxon="true" resultType="java.lang.String">current-dateTime()</xpath>
|
Namespace auditing to aid debugging
Available as of Camel 2.10
A large number of XPath-related issues that users frequently face are linked to the usage of namespaces. You may have some misalignment between the namespaces present in your message and those that your XPath expression is aware of or referencing. XPath predicates or expressions that are unable to locate the XML elements and attributes due to namespaces issues may simply look like "they are not working", when in reality all there is to it is a lack of namespace definition.
Namespaces in XML are completely necessary, and while we would love to simplify their usage by implementing some magic or voodoo to wire namespaces automatically, truth is that any action down this path would disagree with the standards and would greatly hinder interoperability.
Therefore, the utmost we can do is assist you in debugging such issues by adding two new features to the XPath Expression Language and are thus accesible from both predicates and expressions.
Logging the Namespace Context of your XPath expression/predicate
Every time a new XPath expression is created in the internal pool, Camel will log the namespace context of the expression under the org.apache.camel.builder.xml.XPathBuilder
logger. Since Camel represents Namespace Contexts in a hierarchical fashion (parent-child relationships), the entire tree is output in a recursive manner with the following format:
Code Block |
---|
[me: {prefix -> namespace}, {prefix -> namespace}], [parent: [me: {prefix -> namespace}, {prefix -> namespace}], [parent: [me: {prefix -> namespace}]]]
|
Any of these options can be used to activate this logging:
- Enable TRACE logging on the
org.apache.camel.builder.xml.XPathBuilder
logger, or some parent logger such asorg.apache.camel
or the root logger - Enable the
logNamespaces
option as indicated in Auditing Namespaces, in which case the logging will occur on the INFO level
Anchor | ||||
---|---|---|---|---|
|
Auditing namespaces
Camel is able to discover and dump all namespaces present on every incoming message before evaluating an XPath expression, providing all the richness of information you need to help you analyse and pinpoint possible namespace issues.
To achieve this, it in turn internally uses another specially tailored XPath expression to extract all namespace mappings that appear in the message, displaying the prefix and the full namespace URI(s) for each individual mapping.
Some points to take into account:
- The implicit XML namespace (xmlns:xml="http://www.w3.org/XML/1998/namespace") is suppressed from the output because it adds no value
- Default namespaces are listed under the DEFAULT keyword in the output
- Keep in mind that namespaces can be remapped under different scopes. Think of a top-level 'a' prefix which in inner elements can be assigned a different namespace, or the default namespace changing in inner scopes. For each discovered prefix, all associated URIs are listed.
You can enable this option in Java DSL and Spring DSL.
Java DSL:
Code Block | ||||
---|---|---|---|---|
| ||||
XPathBuilder.xpath("/foo:person/@id", String.class).logNamespaces()
|
Spring DSL:
Code Block | ||||
---|---|---|---|---|
| ||||
<xpath logNamespaces="true" resultType="String">/foo:person/@id</xpath>
|
The result of the auditing will be appear at the INFO level under the org.apache.camel.builder.xml.XPathBuilder
logger and will look like the following:
Code Block |
---|
2012-01-16 13:23:45,878 [stSaxonWithFlag] INFO XPathBuilder - Namespaces discovered in message: {xmlns:a=[http://apache.org/camel], DEFAULT=[http://apache.org/default],
xmlns:b=[http://apache.org/camelA, http://apache.org/camelB]}
|
Dependencies
The XPath language is part of camel-core.