tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale Ogilvie" <Dale_Ogil...@trimble.com>
Subject RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl
Date Wed, 08 Aug 2012 04:24:00 GMT
-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org] 

>Again, that class is not a Tomcat class. As far as I can tell, that is party of Jetty's
JSP/EL implementation. 
<snip>
>Anyway, if you start adding JARs from one container into another then all sorts of things
can and will go wrong. I see no way to protect Tomcat against this.

>Mark

So you are saying that Tomcat should not be responsible for preventing app1 from unintentionally
loading a class from app2/WEB-INF/lib/[jetty-jsp-el].jar?

I thought that this was a contravention of Tomcat classloading rules. Is your point that the
jetty jar is doing some "magic" to force its class into another apps classloader tree, and
this sort of thing is actually allowable for an app using "container" jars?

If you could provide some more details on how one can intentionally inject your own classes
into other apps for their use, that would be interesting, but it does sound like a bit of
a security hole.

Note, I don't know very much about the technical details of classloaders, I am just trying
to understand how something occurred which seems to be against how things are supposed to
work.

P.S. The jetty jar actually appeared in app2 due to maven dependencies, it was not added as
a direct dependency for app2.

Dale
Mime
View raw message