| 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 get that app 1 doesn't have an impl in its lib folder, but I would expect the call to be passed to the tomcat shared class loader, whereby tomcat's EL impl is loaded from CATALINA_BASE/lib. You seem to imply that once tomcat has loaded a EL impl into the app2's classloader, that this some how breaks or dirties the tomcat shared classloader so that it can no longer work the way I describe above. Could you spare a minute to explain where my understanding falters? Thanks Chris
