[jira] [Issue Comment Edited] (CAMEL-4799) Umbrella ticket for XPath improvements

["Raul Kripalani (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

    [ 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