tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Petersen" <>
Subject Xalan & Tomcat: sealing violation
Date Mon, 26 Mar 2001 10:20:04 GMT
First - I may have posted this to the wrong list, if so please let me know a more appropriate
place to post this.

I think there is a bug in the way Tomcat (or the JVM) handles class loading of classes.  The
problem is this, I have a servlet (filter actually) that attempts to do some XSLT transformations.
 When the filter tries to get a TransformerFactory a security exception is thrown, java.lang.SecurityException:
sealing violation.  (The entire stack trace is at the bottom)
The root of the problem is when the class loader is trying to load a org.xml.sax.SAXException.
 The resource is correct in that the code source url returned is "file:C:/Program Files/Apache
Group/tomcat/webapps/jdst/WEB-INF/lib/xalan.jar"  the is the xalan.jar file bundled with my
webapp.  The problem arises when the class loader tries to get the package with a call to
"getPackage(pkgname);"  The class loader doesn't have this package and asks it's parent to
see if it can find the package, and sure enough the parent has a package object from org.xml.sax.
 The problem is this package was loaded earlier and it's url is "file:C:/Program Files/Apache
Group/tomcat/lib/crimson.jar", so when the class loader is checking if the package is sealed
it compares the two urls, finds they are not the same and throws the exception.  

A big assumption I have is that what I am doing is legal, I assume that the intention of the
class loading systems is so that the base tomcat code can access it's classes with out worry,
using whatever version of the classes it likes and that web apps can load their own version
of classes without effecting the behavior of tomcat or other web apps.  Is this correct?

Now you can avoid this problem simply by not asking the package if it is sealed against the
code source url.  Is this safe?

If you do that though another sort of configuration separation problem happens, in the crimson.jar
file the property "javax.xml.parsers.DocumentBuilderFactory" is set to "org.apache.crimson.jaxp.DocumentBuilderFactoryImpl",
so if I ask for a new TransformerFactory then I get an instance of "org.apache.crimson.jaxp.DocumentBuilderFactoryImpl",
if I don't want that type of object I can set the property to my own class, e.g. "org.apache.xalan.processor.TransformerFactoryImpl"
but now all the other web apps are forced to deal with my class.  Worse yet, some other webapp
could come along and switch the property on me.  So it appears that there is no sort of "configuration
layering" which I think is a problem.

Any help would be appreciated.

Robert Petersen

Stack Trace:
java.lang.SecurityException: sealing violation
	at Method)
	at org.apache.catalina.loader.StandardClassLoader.findClass(
	at org.apache.catalina.loader.StandardClassLoader.loadClass(
	at org.apache.catalina.loader.StandardClassLoader.loadClass(
	at java.lang.ClassLoader.loadClassInternal(
	at com.orangefood.xsltfilter.Filter.doFilter(
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(
	at org.apache.catalina.core.StandardWrapperValve.invoke(
	at org.apache.catalina.core.ContainerBase.invoke(
	at org.apache.catalina.core.StandardContextValve.invoke(
	at org.apache.catalina.core.ContainerBase.invoke(
	at org.apache.catalina.core.StandardContext.invoke(
	at org.apache.catalina.core.StandardHostValve.invoke(
	at org.apache.catalina.valves.ValveBase.invokeNext(
	at org.apache.catalina.valves.AccessLogValve.invoke(
	at org.apache.catalina.core.ContainerBase.invoke(
	at org.apache.catalina.core.StandardEngineValve.invoke(
	at org.apache.catalina.core.ContainerBase.invoke(
	at org.apache.catalina.connector.http.HttpProcessor.process(

View raw message