We've also hit this problem a few times. I'm not a maven expert here, but would it be possible to create a maven profile that adds the jars for the app servers that need them? When you build using maven and you need them added, you would add the profile. Again, I'm not exactly sure how maven's magic would work under the covers, but at first glance, this seems like something that might help.
-Mark W. From: Ben Smith <[email protected]> To: [email protected] Date: 05/30/2009 04:01 AM Subject: Re: jetty and juel incompatibilities Made it a dependancy of our maven project that also has shindig as a dependancy (as we create our own webapp). We only have the one webapp in our tomcat. HTH On 30 May 2009, at 08:26, Ian Boston wrote: > Ben > Some questions: > > Did you put that in shared/lib or in which the shindig webapp ? > and > Do you run other apps that use el in the same tomcat ? > > (every bit of info helps, thanks) > Ian > > On 30 May 2009, at 08:19, Ben Smith wrote: > >> We have included the juel-api (2.1.1.RC2) to stop the tomcat >> incompatibility. >> >> Don't know if that helps, but thought I'd mention it. >> >> On 30 May 2009, at 06:20, Ian Boston wrote: >> >>> >>> On 29 May 2009, at 23:03, Brian Eaton wrote: >>> >>>> On Fri, May 29, 2009 at 2:22 PM, Wenjun Wu <[email protected]> >>>> wrote: >>>>> I found that the WAR file of the Shindig snapshot 1.1 doesn't >>>>> include the >>>>> juel-2.1.0.jar. That prevented the shindig from working >>>>> correctly in the >>>>> Tomcat. >>>>> It takes time for people to figure out the problem if they just >>>>> follow the >>>>> instruction from the Shindig's download page. >>>>> Could this issue be fixed in the release package? >>>> >>>> OK, we just landed in jar hell [1]. >>>> >>>> If we include the javax.el.* APIs in the shindig war, it breaks >>>> compatibility with jetty and (I think) some versions with Tomcat. >>>> >>>> If we don't include the javax.el.* APIs in the shindig war, it >>>> breaks >>>> compatibility with other versions of Tomcat. >>>> >>>> It's easier for deployers to add jars than remove them, so I'm >>>> inclined not to ship the javax.el.* APIs. >>>> >>>> One other option would be to use reflection for this, but that gets >>>> messy very quickly. >>>> >>>> [1] http://en.wikipedia.org/wiki/Classloader#JAR_hell >>> >>> +1 >>> The exception comes from the JSP compiler, which is part of the >>> container, >>> without the API in the containers shared space, it probably cant >>> compile any EL, pointing to a container config issue. >>> >>> Ian >> >
