a bug report needs to be filed for the maven-dependency apache-tomcat-maven-plugin that caused the error the problem is since the plugin was rolled out to its new home..the latest plugin version 2.1 has no content which displays what the new version is supposed to accomplish https://issues.apache.org/jira/browse/MTOMCAT#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel
If the apache-tomcat-maven-plugin fix is in version 2.1 deprecate previous versions and pull that version from the dependency list of each affectect parent pom and rebuild all affected distros In other words pull the contanimated version from all distros If the apache-tomcat-maven-plugin fix is NOT in 2.1 Lets 1)file a report 2)grab the source 3)implement a fix 4)notify interested parties 5)commit the fix to source control ..tag it uniquely (e.g. 2.1.1) Martin ------------- > Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl > cannot be cast to org.apache.jasper.el.ELContextImpl > Date: Fri, 10 Aug 2012 16:13:32 +1200 > From: dale_ogil...@trimble.com > To: users@tomcat.apache.org > > -----Original Message----- > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] > > >1. Tomcat 7.0.26 and earlier has static field > JspApplicationContextImpl.ExpressionFactory, so the EL implementation is > effectively shared between web applications. > > Thanks for that info about the earlier bug in 7.0.26 Konstantin. > > >2. I do not know why you are observing the issue with 7.0.27. > >Either the fix was incomplete, > >or maybe the JSPs were compiled with an earlier version of Tomcat. Try > clearing the work folder so that they are recompiled. > >or it is caused specifically by "other vendor" using jasper package > names in their classes. E.g. when some jasper classes were loaded by > Tomcat by the first time, it might be loaded from 3rd party JAR instead > of Tomcat. > > The work directory would have been empty when the apps started up with > 7.0.27, it wasn't an in place upgrade from the earlier 7.x version. I > also specifically cleaned the app1 work directory while I was trying to > figure out what was happening. > > It does concern me that there was a known issue that was fixed, and here > I am seeing this EL impl instance sharing between apps in the "fixed > version". > > Mark's "Don't do that" in terms of loading container jars in apps > generally is a solution, but the trick is we didn't create the problem > intentionally. We got scuppered by a maven dependency and Tomcat didn't > protect us. Ideally bad behaviour of an app should not break the other > apps in the container. > > Dale > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
