tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl
Date Thu, 09 Aug 2012 19:29:32 GMT
On 09/08/2012 11:41, chris derham wrote:
> | I am 95% certain of what is happenning but haven't tested this. It will
> help your understanding if you read the EL specification, specifically the
> section in the Javadoc regarding how implementations are discovered.
> | Tomcat implements these rules. It is possible for an EL implementation to
> be loaded from an application. Everything will be fine EL-wise for the
> application that shipped with the EL implementation but things will
> | fall apart for any other application that tries to use EL since the
> implementation classes will not be visible.
> Mark,
> I don't understand one key component of your response. I don't pretend to
> understand the internals of tomcat, but I thought that I had a good grasp
> on how things were supposed to work. Please forgive me if I ask something
> stupid.
> You seem to say that the EL implementation will be loaded from the app2, as
> it has an implementation present in its lib. You then say that this won't
> be visible to app 1, presumably because this class is loaded into the
> app2's class loader. That bit matches up with my understanding on app class
> loaders in web containers - each app has its own, and they are separate
> preventing leakage from one app to another. The bit I don't really
> understand is when app 1 tries to run some EL code, surely the same
> mechanism should kick in and load an EL implementation.

I strongly suspect - but haven't run a test to confirm - that the
implementation obtained from app2 is cached by the EL discovery
mechanism so that app1 is given the same instance.

It is pretty much a given that app1 will then break. The only question
is how long it will take before app1 hits a point where it realises it
is working with an instance of a class it can't load.

I'd need to do some testing to confirm exactly what is going on but the
reported behaviour is - so far - consistent with what I think is happening.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message