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
