englishteeth.co.uk

Something that felt like forever to track down…

A test running problem free on the test server was throwing a transformer error locally:

javax.xml.transform.TransformerException:
Had IO Exception with stylesheet file: C:\jboss-4.0.3SP1\server\default\conf\documentservice\pmi\include.xslt
at org.apache.xalan.processor.TransformerFactoryImpl.processFromNode(TransformerFactoryImpl.java:126)
...


On the surface, it looked like there was no difference in the environments; same deployed war file, same JBoss version, same Java version, same everything. Obviously something was different…

Xalan 2.7.0 was distributed in the WEB-INF/lib of the war, but stepping through the code on the failing local server, the byte code didn’t match the attached source. It wasn’t 2.7.0 being used, it was actually the 2.6.0 version shipped with JBoss (found in lib/endorsed).

It turns out that libraries in the lib/endorsed directory are considered system libraries by virtue of being loaded by the System and bootstrap class loaders and as such being used in preference to deployed war files version. (It should be noted that this is an older version of JBoss, namely 4.0.3 SP1.)

That explained why the wrong class was being picked up locally, but not why it worked in the test server environment.

The main difference was that the server was being run as a service on the test server and via a batch file locally.

Purely by chance, the endorsed.dirs parameter had been missed from the configuration of the service wrapper.

wrapper.java.additional.2=-Djava.endorsed.dirs=%JBOSS_HOME%\lib\endorsed

Striking this out of the local batch file, sanity returned once more.

rem set JBOSS_ENDORSED_DIRS=%JBOSS_HOME%\lib\endorsed

Removing Xalan and Xerces from lib\endorsed would have much the same effect and is proposed in this jira task at jboss.org

I wanted to generate some sample XML from an XSD I was given and I was struck by the lack of resources outside of the over bloated Altova tools and their misguided clones much more heavy weight options that seem overkill for what I’m trying to do.

I was actually hoping to find a style sheet that could do the job, but I had no luck.

Along the way though, I did find Liquid XML Studio which in it’s freeware incarnation has some nice schema viewing, editing and generation features. There’s also an integrated web service browser



and although, I haven’t played with it much yet, there’s an XPath expression builder in there too.



My only disappointment is the lack of XSLT support, at least in the freeware version. I’m looking for a reasonable successor to MarrowSoft Xselerator which is no longer supported or being sold by TopXML. Xselerator is not compatible with Microsoft Internet Explorer 7, which I has not actually proved a problem for me yet, but it’s days must be numbered.

I’m not adverse to paying for software (Xselerator wasn’t free), but I must admit to being put off a little by hobbled versions. An issue covered much better than I could by Jeff Atwood, here.

My favourite Cyberlink love/hate thing comes to mind; Power DVD Ultra, Power DVD Deluxe, Power DVD Standard or Power DVD OEM. Mmm, now let me see… do any of them work reliably?

I don’t mind admitting that despite it being pretty straight forward, I have been caught out by this more than once. So, in an attempt to prevent that Doh! moment again in the future…

The scenario revolves around an XSL Stylesheet that references another resource, be it an XML file for lookups, another stylesheet or whatever. Everything works a treat when processed locally, but blows up when invoked in its Java context. “Can not load requested doc:” or something similar.

This is where brain failure kicks in and I can’t think where the resource should be and waste time moving files around, changing references and trawling the web. In fact the reason the document cannot be found is simply because I haven’t told the transformer where, or more acurately how, to look for it!

The following is a simple reslover that looks on the class path for the missing file.

	public class ResourceResolver implements URIResolver {

		private static final String RESOURCE_PREFIX = "resource://"; 

		public Source resolve(String href, String base)
				throws TransformerException {
			if (!href.startsWith(RESOURCE_PREFIX))
				return null;
			try {
				if (log.isDebugEnabled()) {
					log.debug("Resolving stylesheet resource: " + href);
				}
				String resource = href.substring(RESOURCE_PREFIX.length());
				ClassLoader loader = getClass().getClassLoader();
				InputStream is = loader.getResourceAsStream(resource);
				return new StreamSource(is, resource);
			} catch (Exception ex) {
				throw new TransformerException(ex);
			}
		}
	}

Building on a previous post Oracle “Is Numeric” a similar thing is possible using XSLT (or more accurately, XPATH) too…

<xsl:if test="string-length(translate(node(),' +-.1234567890', ' ')) > 0">
  <xsl:text&gt;not numeric&lt;/xsl:text>
</xsl:if>

Not exactly ground breaking stuff, but something similar did turn out useful for extracting the non numerical area component of a post code (i.e. the SO bit of SO53 3RY).

substring-before(translate($postcode,'1234567890', '----------'),'-')

Which I thought was close enough to the oracle is numeric implementation to make comment.

In order to augment a piece of XML using XSLT, the base requirement is to make sure the existing document or fragment is preserved. This is done by recursively copying all the elements, attributes etc. as defined by the W3C Recommendation for copying.

<xsl:template match="@*|node()">
  <xsl:copy>;
    <xsl:apply-templates select="@*|node()"/>
  </xsl:copy>
</xsl:template>

The main things going are here is the matching of every attribute with “@*” and every child node (node() being shorthand for child::node()). As mentioned in the W3C Recommendation, the root node is considered a special case and is implicit, therefore “@*|node()” finds everything else.

This is all well and good, but the benefit of this recurisve copying is making the exceptions or augmentations to the input XML. To implement these we simply add templates matching the point of change:

<xsl:template match="existingElement" >
  <xsl:element name="replacementElement">
    <xsl:text>Some content for the new element</xsl:text>
  </xsl:element>
</xsl:template>

A really good description and set of examples of doing this sort of thing (also known as the identity template) can be found here.