You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Robert Petersen <ro...@orangefood.com> on 2001/03/26 12:20:04 UTC
Xalan & Tomcat: sealing violation
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.
Thanks,
Robert Petersen
Stack Trace:
java.lang.SecurityException: sealing violation
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:217)
at org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:648)
at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:987)
at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:906)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
at com.orangefood.xsltfilter.Filter.doFilter(Filter.java:40)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:251)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897)
at java.lang.Thread.run(Thread.java:484)
RE: Xalan & Tomcat: sealing violation
Posted by Kevin Jones <ke...@develop.com>.
Robert,
this is a well known issue that is being worked on. Check back on the list
over the last couple of days for another discussion of this :-)
Kevin Jones
DevelopMentor
www.develop.com
> -----Original Message-----
> From: Robert Petersen [mailto:robert@orangefood.com]
> Sent: 26 March 2001 11:20
> To: tomcat-dev@jakarta.apache.org
> Subject: Xalan & Tomcat: sealing violation
>
>
> 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.
>
> Thanks,
> Robert Petersen
>
> Stack Trace:
> java.lang.SecurityException: sealing violation
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:225)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:217)
> at
> org.apache.catalina.loader.StandardClassLoader.findClass(StandardC
> lassLoader.java:648)
> at
> org.apache.catalina.loader.StandardClassLoader.loadClass(StandardC
> lassLoader.java:987)
> at
> org.apache.catalina.loader.StandardClassLoader.loadClass(StandardC
> lassLoader.java:906)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> at com.orangefood.xsltfilter.Filter.doFilter(Filter.java:40)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
onFilterChain.java:180)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp
> erValve.java:251)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardConte
> xtValve.java:196)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValv
> e.java:161)
> at
> org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngine
> Valve.java:159)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
> at
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProce
> ssor.java:818)
> at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor
> .java:897)
> at java.lang.Thread.run(Thread.java:484)