Has the following ever happened to you? You show up to work one morning and your boss tells you, “I need you to take this data and turn it into XML.” Well, this has happened to me, and in this blog post I’m going to show you how to do this quickly.
The other day I helped a customer figure out a little XPath problem: they had an XML document and wanted to process it depending on an XPath expression. Here’s the Mule config that shows what we were trying to achieve:
It is pretty common that Mule messages contain XML as a payload and that those messages need to be validated/transformed. XML documents can be automatically validated using XSD, though those validations are structural and sometimes we need to manually code some validation in plain Java (especially in complex scenarios like validating references, existence conditions and value dependencies).
Configuring Mule involves XML, and though using a decent XML editor can help a lot (thanks to the contextual help it provides from Mule’s schemas), there is still a enough angle brackets to warrant a coffee break as projects get more complicated.
As the number of services in a Mule project increases, so does the amount of noise in its configuration files, making it harder to understand and maintain them. We recommend splitting service configuration files, but in Mule 3 we’ve decided to go further and tackle this problem with the introduction of pattern-based configuration.
When I recently switched to Eclipse Galileo, I noticed that a Mule configuration file that had previously validated correctly now had validation errors. Since I did not change the file, something in Galileo’s validation of XML files must have changed.