JUEL is happily using the javax.el.* API provided by jetty. We may run into future trouble if the javax.el API isn't stable and we end up with different servlet containers providing incompatible versions.
On Tue, May 5, 2009 at 10:44 PM, Ian Boston <[email protected]> wrote: > That sounds good to me. At one point there was mention that JUEL would not > use the javax.el.* api provided by jetty. So does that mean that the impl > from the jboss repo has fixed that problem, or am I imagining things (either > is perfectly possible). > Ian > > > On 5 May 2009, at 21:47, Brian Eaton wrote: > >> The "split API from implementation" approach that Paul suggested >> earlier seems to work. respository.jboss.com is already hosting a >> JUEL build that splits the implementation jar from the interface jar. >> So the approach would be: >> >> 1) Depend on juel-api and juel-impl from repository.jboss.com. >> 2) Mark juel-impl as a normal dependency, and juel-api as a "provided" >> dependency >> 3) maven won't automatically bundle juel-api into the war files. >> 4) If folks are using a servlet engine that provides juel-api or >> equivalent, things just work. >> 5) If folks are using a servlet engine that does not provide juel-api, >> they need to bundle up juel-api themselves. >> >> I think this will make tomcat6 integration easier as well: >> >> http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=105008#Index-HowdoIrunShindigonTomcat6underEclipse%3F >> >> I'll send a code review and submit tomorrow if no one objects. >> >> Cheers, >> Brian >> >> On Fri, May 1, 2009 at 10:42 AM, Ian Boston <[email protected]> wrote: >>> >>> On 1 May 2009, at 17:29, Brian Eaton wrote: >>> >>>> On Fri, May 1, 2009 at 2:30 AM, Ian Boston <[email protected]> wrote: >>>>> >>>>> Have you tried setting the context classloader to the webapp >>>>> classloader >>>>> around that method call ? >>>> >>>> I don't see a method call to fix, unfortunately. This happens when >>>> jetty tries to compile a jsp, there is no shindig code in the stack >>>> until too late. >>>> >>>> I think this is the flow. First: >>>> - jetty starts shindig with webapp class loader >>>> - shindig loads ExpressionFactory and ExpressionFactoryImpl with web >>>> app class loader >>>> >>>> Later: >>>> - jetty starts JSP compiler with context class loader (system class >>>> loader, maybe?) >>>> ***bug*** load ExpressionFactory with context class loader >>>> - switch to web app class loader >>>> - JSP compiler calls ExpressionFactory.newInstance >>>> - newInstance finds ExpressionFactoryImpl from web app class loader >>>> - then there's a cast to the wrong version of ExpressionFactory.class, >>>> and we die. >>>> >>>> If I'm right, I think we've found a jetty bug. I might be wrong. I >>>> haven't found the right version of the jetty code to step through to >>>> see what's going on. >>> >>> >>> Yes sounds like a bug with the jsp compiler. >>> What happens in Tomcat with the same glassfish el jar in shared ? >>> The fix from the earlier version might just have been due to no el jar in >>> shared ? >>> Ian >>> >>> >>> > >
