XML, Xalan, Endorsed dirs and &..

So recently, we’ve been working on a project that makes use of OpenSAML. As it turns out OpenSAML required newer Xalan libraries (2.7.1 to be precise), the kind that don’t ship with the older incarnation of jboss we are using for the project – version 4.02. Some of you might be more familiar with the jboss system properties and will know there’s a property jboss used specifically to override the standard xml libraries that ship with the jdk/jre (entry in the console output bolded and marked with a *). Jboss will allow you to pass in as a parameter the location for a variable known as “java.endorsed.dirs.” The purpose of this property is to map the file path to the Xalan libraries you would like for jboss to use as the Xalan implementation during runtime.

-Djava.endorsed.dirs=file://path/to/your/xalan/libraries

So if you have other installed applications running in different instances, you wont have to upgrade every instance you’re running concurrently, instead you can override a specific instance’s use of Xalan libraries by using this parameter in the run script. I’m not quite sure what version of Xalan ships with jboss 4.02, but when we upgraded the first thing we noticed was that any xml text in like “&” rendered as “&” post xslt instead of rendering as “&” (presumably a fix set forth as Xalan matured):

<xsl:param name="url">
	http://www.some-url.com/path.do?parameter=value&otherParameter=otherValue
</xsl:param>

turned into

http://www.some-url.com/path.do?parameter=value&amp;amp;otherParameter=otherValue

If you intend to upgrade your Xalan libraries I would think that you might need to do some type of regression testing to make sure upgrading these xml centric libraries doesn’t inadvertently wind up breaking xml dependent sections of your application. It should be noted if you randomly toss upgraded xalan jars into your application you’re bound to run into all kinds of crazy exceptions. I’ve seen jboss complain about login-conf.xml, missing class libraries, weird servlet allocation exceptions, class not founds – all kinds of misleading problems that seem unrelated to xalan jar collisions or wierded out dependancies.

Bottom line is if you need to upgrade Xalan, stick to using java.endorsed.dirs, and pass in the -Djava.endorsed.dirs param into the jboss run script if you want to override a specific instance.

Comments (3)

  1. 7:49 AM, January 28, 2010Marc  / Reply

    Were you able to scope the XML classpaths to specific applications?

  2. 10:04 AM, January 28, 2010Ant  / Reply

    We tried setting individual classpath loaders for the war file in question, but that’s when we ran into OpenSAML-implementing classes throwing ClassNotFoundExceptions, which claimed that the “Servlet Could Not Be Allocated”. It’s as if trying to use the jboss 402 xalan libraries while trying to load the xalan libraries separately, and by the war file creates some kind of wall that didn’t allow the SAML related servlets to load properly. In the end we gave up and just changed the location of the endorsed libs for that instance and it seems to have worked out. But not before pulling all our hair out and yelling at the compiler.

  3. 11:37 AM, January 28, 2010Marc  / Reply

    Either JBoss has a history of being unable to consistently control classloading scope or I have a history of misunderstanding how it’s supposed to work.

Leave a Reply

Allowed Tags - You may use these HTML tags and attributes in your comment.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Pingbacks (0)

› No pingbacks yet.