You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ray Allis <ra...@boeing.com> on 2000/11/02 21:53:35 UTC
Re: [ANNOUNCE] Tomcat 4.0 Milestone 4 - cocoon security problem?
"Craig R. McClanahan" wrote:
>
> We're pleased to announce the availabililty of milestone 4 of the Tomcat
> 4.0 servlet container and JSP engine. Compared to milestone 3, this
> release reflects the following changes:
> Come and get it!
Got it! Ooops! I lost cocoon!
2872427 Oct 31 09:38 ../archive/jakarta-tomcat-4.0-20001031.tar.gz
runs cocoon,
2870683 Nov 2 08:32 ../archive/jakarta-tomcat-4.0-m4.tar.gz
does not.
--
My installation procedure was to unzip (gzip) 4.0-m4, rename the
directory
to jakarta-tomcat, 'cp -r' [old]/webapps/cocoon to
jakarta-tomcat/webapps
cd to jakarta-tomcat and type bin/startup.sh. JSP and servlets
otherwise
look fine.
--
Cocoon 1.8.1-dev
Publishing Engine could not be initialized.
java.lang.SecurityException: sealing violation
at
java.net.URLClassLoader.defineClass(URLClassLoader.java:234)
at
java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native
Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.java:188)
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 java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at
java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at
java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native
Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.java:188)
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 java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at
java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at
java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native
Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.java:188)
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
org.apache.cocoon.framework.Manager.create(Manager.java:91)
at org.apache.cocoon.Engine.(Engine.java:139)
at org.apache.cocoon.Engine.getInstance(Engine.java:223)
at org.apache.cocoon.Cocoon.init(Cocoon.java:141)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:755)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:229)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:165)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:1876)
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:343)
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:785)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:902)
at java.lang.Thread.run(Thread.java:484)
--
Ray Allis - ray.allis@boeing.com
Re: Tomcat 4.0 Milestone 4 - cocoon security problem?
Posted by Ray Allis <ra...@boeing.com>.
"Craig R. McClanahan" wrote:
>
> Could you try me an experiment?
>
> * Comment out the <servlet> declaration
> for the JSP servlet in
> $CATALINA_HOME/conf/web.xml
I must not be commenting correctly; if I comment this out I get
"Page contains no data" on http://memes.sea.boeing.com:8080
(index.html).
> * Temporarily remove "crimson.jar" and "jaxp.jar"
> from $CATALINA_HOME/lib
>
> * Restart and see if Cocoon works
Well, yes! It does! Of course JSP doesn't. (web.xml is unchanged)
> If you need Cocoon *and* JSP, I don't have a good answer for you right at the moment ...
>
> Craig McClanahan
Well, I -can- run two tomcats for a while; this is only a demo system,
after all.
(And actually I prefer XSP to JSP anyway ;))
Thanks!
Ray Allis
Re: [ANNOUNCE] Tomcat 4.0 Milestone 4 - cocoon security problem?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ray Allis wrote:
> "Craig R. McClanahan" wrote:
> >
> > We're pleased to announce the availabililty of milestone 4 of the Tomcat
> > 4.0 servlet container and JSP engine. Compared to milestone 3, this
> > release reflects the following changes:
>
> > Come and get it!
>
> Got it! Ooops! I lost cocoon!
>
Groan ... BOY do I hate class loaders :-)
Could you try me an experiment?
* Comment out the <servlet> declaration
for the JSP servlet in
$CATALINA_HOME/conf/web.xml
* Temporarily remove "crimson.jar" and "jaxp.jar"
from $CATALINA_HOME/lib
* Restart and see if Cocoon works
The right long term answer is that Xerces becomes JAXP-1.1 compatible, so that system
administrators can simply use that instead of Crimson if they want to. In the mean time,
Jasper (the JSP servlet) has a requirement for Crimson because it is the only JAXP-1.1
compatible parser available (we needed the portable SAX2 support).
If you need Cocoon *and* JSP, I don't have a good answer for you right at the moment ...
Craig McClanahan