Friday, December 29, 2006

XPath Query

One minor annoyance while working with Celtix (not really a Celtix issue) was a content based routing test. One thing you find out when working with open-source projects is that they can be made up of many open-source projects. I had the following issue with an XPath query.

This query:

//urn:CustomerAccount/urn1:accountdescription = 'yoda'


Is really not the same as this query:

//*:CustomerAccount/*:accountdescription = 'yoda'


In Celtix ESB land, this last query (which is a valid XPath query) throws an error. It turns out the XML parser they are using does not support wildcards like this. Instead it will match any prefix as long as the prefix is presence. In other words, urn1:CustomerAccount and urn:CustomerAccount will both match the query. That's cool once you know it, but it is annoying when you don't. Dom4j is the culprit. No relation to Celtix but used in Mule which is used in the Celtix ESB.

You just have to do a little family tree tracing when using open-source solutions.

2 comments:

Anonymous said...

Hi Mark,

Is it a fixable problem? If there's anything we can do (bugfix, upgrade, etc.), could you please file an issue at http://mule.mulesource.org/jira ?

Cheers,
Andrew
MuleSource

Mark Griffin said...

Hi Andrew,
It probably is although I think this is the project http://www.dom4j.org/ with the issue. I'll dig there first and see if it already exists.

Markg