-----Original Message-----
From: Mark Thomas [mailto:ma...@apache.org]
>Not quite. My point was the loading of the EL implementation is likely to be
>triggered by user code. If the webapp class loader is the TCCL loader than
>classes from the web app will be loaded before those from the >container. If
>the web app contains container classes then it is possible that they get
>loaded from the webapp rather than from Tomcat.
>(Enabling the security manager enables additional class loading checks that
>would stop this). Those classes from the webapp then have references held to
>them. They will work right up unto the point Tomcat tries to >access the class
>outside of the webapp they were loaded from.
>
>Mark
I'm still not quite sure what you are saying matches exactly what I'm seeing
Mark. The webapp classloader IS the TCCL loader. No problem at all that the app
containing the "container classes" will load those in preference to the actual
Tomcat ones. Ok.
However, what I see is this, in time order:
1. App2 (containing container classes) is deployed by TC at TC startup
2. App1 (not containing container classes) is deployed by TC at TC startup
3. A web request is made of App1 to load a JSP that uses EL
4. The vm ("-verbose:class") reports class LOAD from app2:
[Loaded javax.el.ExpressionFactory from
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]
5. Class cast exception occurs somewhat later
So, it appears to me that the class *loading* is occurring "from" app1 in step
4. I'm only pushing this because it kind looks "buggy" to me.
Dale
