Christopher Oliver wrote:
OK. I get it. The old version of Xalan that comes with the JDK incorrectly throws that exception when processing one of Cocoon's stylesheets. By placing a new version of Xalan in Tomcat's endorsed directory (http://java.sun.com/j2se/1.4/docs/guide/standards) the newer version of Xalan is loaded first.
This is a common classloading problem but it is exacerbated by poorly designed interfaces, in this case the culprits seem to be javax.xml.transform.TransformerFactory (which relies on a system property (why is this bad? Think global variable)) and org.apache.avalon.excalibur.xml.xslt.XSLTProcessor (which relies on thread context class loader (why is this bad? Again, think global variable)). The reason both resort to using external variables is that the interfaces they define are missing one or more necessary parameters. I don't know how much such issues have been discussed on this list, so I won't go into this in more detail here. If it weren't for these additional problems, it wouldn't be necessary to resort to Sun's "endorsed" directory hack, a Cocoon component could simply load the implementation it needed using a private class loader.
This is a little bit more complicated : the message you had ("The output format must have a '{http://xml.apache.org/xslt}content-handler' property!") is issued when Xalan cannot correctly get the contents of "org/apache/xalan/templates/output_html.properties" (or "_xml", depending on the output type). And if you compare those in Xalan 2.4.1 (Cocoon's HEAD) and in the JDK 1.4, you will see a bug-fix that prevented Xalan to load it properly.
What seems to happen is that the Xalan in WEB-INF/lib loads this property file but, instead of getting the one in its own jar, gets the one in JDK's runtime.jar. Xalan 2.4.1 seems to be stricter than JDK's Xalan when loading this file, and thus fails.
A possible explanation of this behaviour is a bug in Catalina's WebappClassLoader. A quick look at it shows that the policy for delegating calls to the parent classloader seems to be different for resources and classes. Hence the solution of moving Xalan to tomcat/commons/endorsed which unify the source for both resources and classes.
We should dig in WebappClassLoader, and if this reveals to be a bug, send it to Tomcat-dev.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
