Schema Validation Filter Gotchas with Mule Studio

gowebing

Earlier this month, I was delivering a proof of concept around Mule that required the use of the schema validation filter. The use case was pretty simple. XML messages comes in through a SOAP request, and some fields in the incoming message had to be validated against a bunch of XML schemas.

Well this is the perfect use case scenario for the Schema Validator that is provided out of the box with Mule. Its an element you can drop from Mule Studio palette straight into your flow.

schema-validator

schema-validator

Configuration of this element is a bit tricky. This accepts a comma separated list of schemas to validate the payload against. Fair enough, but you immediately face the first problem. How to come up with a URL that works both in Mule Studio and in Mule standalone if your schemas are part of the classpath?

Usually in Spring, you do this by pre-pending your URL with “classpath:”. Unfortunately this does not work with this filter. We solved the issue by placing the schemas under the src/main/resources folder in Mule Studio. From the schema validation filter, we referred to them using the ${app.home} variable:

<mulexml:schema-validation-filter schemaLocations="${app.home}/classes/MyXsd1_v2.1.0.xsd,${app.home}/classes/xsd/MyXsd2_v1.2.0.xsd" returnResult="true"/>
The second issue that immediately comes up is that any xs:imports or xs:includes in your schemas are happily ignored by the schema validator. The schema validator will fail on startup with an exception that looks similar to the following (exception detail removed for simplicity). 
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'schemaValidator': Invocation of init method failed; nested exception is org.mule.api.lifecycle.InitialisationException: src-resolve: Cannot resolve the name 'xxxyyy' to a(n) 'type definition' component.
	...
Caused by: org.mule.api.lifecycle.InitialisationException: src-resolve: Cannot resolve the name 'xxxyyy' to a(n) 'type definition' component.
	...
Caused by: org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'xxxyyy' to a(n) 'type definition' component.
	...
This is due to the class; javax.xml.validation.SchemaFactory. Mule’s schema validation filter uses this class to build the schemas to be able to validate against. This factory class ignores any XSD ‘includes’ and ‘imports’. (See here for more information.)

Luckily there is a solution. Mule’s schema validation filter allows you to configure a custom resource resolver. This is the class that is used to load external resources, like XSD ‘includes’ and ‘imports’. We have written a very simple resource resolver that loads the external resources from the classpath:

package com.ricston.xml;

import java.io.IOException;
import java.io.InputStream;

import org.apache.xerces.dom.DOMInputImpl;
import org.mule.util.IOUtils;
import org.w3c.dom.ls.LSInput;
import org.w3c.dom.ls.LSResourceResolver;

public class ClasspathResourceResolver implements LSResourceResolver {

	@Override
	public LSInput resolveResource(String type, String namespaceURI, String publicId, String systemId, String baseURI) {

		try {
			InputStream resource = IOUtils.getResourceAsStream(systemId, getClass());
			return new DOMInputImpl(publicId, systemId, baseURI, resource, null);
		} catch (IOException e) {
			e.printStackTrace();
			return null;
		}
	}
}
As you can see, it is extremely simple. Just 2 lines of Java code. The idea here is that we are loading the external resource passed in by the SchemaFactory by using the Mule IOUtils library. Once loaded, we have to pass back an instance of org.w3c.dom.ls.LSInput. We used  org.apache.xerces.dom.DOMInputImpl to help us with that.

The last step is now to configure the schema validation filter to use our custom resource resolver:

<spring:bean id="classpathResourceResolver" name="classpathResourceResolver" class="com.ricston.xml.ClasspathResourceResolver"/>
 
<mulexml:schema-validation-filter schemaLocations="${app.home}/classes/MyXsd1_v2.1.0.xsd,${app.home}/classes/xsd/MyXsd2_v1.2.0.xsd" returnResult="true" resourceResolver-ref="classpathResourceResolver"/>
Of course you can code your custom resource loader to load resources from absolute paths, relative paths, or any other method that you would like to implement. It’s simple enough to take our  ClasspathResourceResolver and convert it to meet your needs.

Another issue that I found with this filter is the way it handles the errors. If you supply it with an XML that does not match any schema, it silently blocks your message. There won’t be anything displayed in the logs by default. To see the errors, you need to configure the SchemaValidationFilter class to log to debug level through log4j:

log4j.logger.org.mule.module.xml.filters.SchemaValidationFilter=DEBUG
We are going to conclude this blog post by saying that the out of the box schema validation filter of Mule is quite useful for obvious reasons, but to exploit its full potential does require a bit of configuration work.

 

 

 

 

Top