[
https://issues.apache.org/jira/browse/CAMEL-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178713#comment-13178713
]
Raul Kripalani edited comment on CAMEL-4799 at 1/3/12 1:15 PM:
---------------------------------------------------------------
After analysing the possibility of making namespace handling more intelligent
so that Camel does some magic behind the scenes for you, I think it is not a
good idea. It can easily lead to a scenario where XPath expression would no
longer be deterministic and could cause more woes than being useful. I
considered various possibilities:
* Evaluating the XPath expression within the default namespace -> but JAXP
doesn't provide a mechanism for doing so
* Automatically discovering the default namespace and setting it in the XPath
expression -> but JAXP doesn't provide a mechanism for doing so
* Automatically "learning" [prefix -> namespace] bindings from messages, but
prefixes are volatile and they can change with each message
So instead, I decided to create an option that dumps to LOG all [prefix ->
namespace] mappings in the incoming message, to facilitate debugging.
Additionally, every time a new XPath expression is added to the pool, the
NamespaceContext is dumped too. With this, the user can compare the namespaces
known to the XPath exp. with the incoming one and easily spot mistakes. This is
documented in CAMEL-4852.
was (Author: raulvk):
After analysing the possibility of making namespace handling more
intelligent so that Camel does some magic behind the scenes for you, I think it
is not a good idea. It can easily lead to a scenario where XPath expression
would no longer be deterministic and could cause more woes than being useful. I
considered various possibilities:
* Automatically setting the default namespace in the XPath expression -> but
JAXP doesn't provide a mechanism for doing so
* Automatically "learning" [prefix -> namespace] bindings from messages, but
prefixes are volatile and they can change with each message
So instead, I decided to create an option that dumps to LOG all [prefix ->
namespace] mappings in the incoming message, to facilitate debugging.
Additionally, every time a new XPath expression is added to the pool, the
NamespaceContext is dumped too. With this, the user can compare the namespaces
known to the XPath exp. with the incoming one and easily spot mistakes. This is
documented in CAMEL-4852.
> Umbrella ticket for XPath improvements
> --------------------------------------
>
> Key: CAMEL-4799
> URL: https://issues.apache.org/jira/browse/CAMEL-4799
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, camel-spring
> Reporter: Raul Kripalani
> Fix For: 2.10
>
> Attachments: xpathBalancingAndNamespaceTracing.diff
>
>
> As agreed with Claus Ibsen over IRC, this ticket will group several XPath
> language improvements as sub-tasks. At least the following will be included:
> * Balance up the XPath Java DSL with Spring DSL, namely to be able to specify
> Saxon as the XPathFactory from Spring DSL
> * Crank up the logging for more verbosity when dealing with namespaces and
> during the evaluation process
> * Improve namespace handling to make it more intelligent (e.g. if the XML doc
> has a default namespace and no other namespaces, and the XPath expression
> doesn't specify one, assume that the expression should be evaluated against
> the default namespace)
> * Result QName definition to work with Saxon Object Model and XPath 2
> constructs which are not embraced by JAXP (e.g. sequences), and possibly some
> type converters (still under evaluation)
> * Balance up the Scala DSL if necessary
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
