On 07/08/2012 00:24, Dale Ogilvie wrote: > Daniel Mikusa [mailto:dmik...@vmware.com] wrote: > >> You would be using a shared class loader if you are placing JAR >> files used by multiple deployed web applications into the >> $CATALINA_BASE/lib or $CATALINA_HOME/lib directory. Are you >> placing any JAR files into those folders? > > We have placed three JDBC driver jars in $CATALINA_HOME/lib. I > presume this is irrelevant to this issue. The class in question > org.apache.jasper.runtime.ELContextImpl only appears to be in a jar > located in app2/WEB-INF/lib, yet it is being loaded for app1. I have > verified that the class is NOT in $CATALINA_HOME/lib. If we remove > app2 from tomcat, the ClassCastException disappears from app1. > Further, removing the jar containing > org.apache.jasper.runtime.ELContextImpl from app2 also resolves the > issue. > > There does seem to be a problem that app2 is sharing classes with > app1 from app2/WEB-INF/lib. How can this happen?
Again, that class is not a Tomcat class. As far as I can tell, that is party of Jetty's JSP/EL implementation. What on earth Jetty is doing using an ASF namespace I have no idea. It looks to be a Jetty 6 issue (i.e. 2 major versions ago) so not one we need to worry about too much at this point. 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
