Have you tried setting the context classloader to the webapp
classloader around that method call ?
eg
ClassLoader webappClassLoader = this.getClass().getClassLoader();
ClassLoader contextClassLoader =
Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(webappClassLoader);
....
} finally {
Thread.currentThread().setContextClassLoader(contextClassLoader);
}
Downgrading will fix it here, but there will be integrators running
6.1.x and later and I saw reports of problems with other webapp
containers.
Ian
On 1 May 2009, at 02:42, Brian Eaton wrote:
On Thu, Apr 30, 2009 at 10:41 AM, Ian Boston <[email protected]> wrote:
well it could be, but [1] Loads the ExpressionFactoryImpl possibly
using the
context classloader.
see [2] all depends what the context classloader is at the time.
Ian
[1]
http://www.java2s.com/Open-Source/Java-Document/Scripting/JUEL/javax/el/FactoryFinder.java.htm
[2]
http://www.java2s.com/Open-Source/Java-Document/Scripting/JUEL/javax/el/ExpressionFactory.java.htm
I think we're borked when we hit ExpressionFactory.newInstance, before
the FactoryFinder code runs. For some reason the class loader being
used by jetty to load ExpressionFactory is not the webapp class
loader.
I tried switching to a different juel build that splits out javax.el.*
from de.odysseus.*, but that causes compile time failures since we do
actually rely on javax.el.
There's a suggestion that dropping down to an earlier jetty build
helps: http://www.nabble.com/Integrating-Apache-Camel-td16302997s2369.html
.
Seems like the wrong solution, but if it works I'd be willing to live
with it.
(Still waiting for maven to finish pulling down jetty 6.0.0 so I can
see if it works.)
Cheers,
Brian
