Luca Morandini skrev:
Daniel Fagerstrom wrote:
Luca Morandini skrev:
Patrick Refondini wrote:
shouldn't it be :
-Dmaven.war.shieldingclassloader=false
Thanks for this bit of information, but Cocoon doesn't run yet.
I did:
mvn -Dmaven.test.skip=true -Dmaven.war.shieldingclassloader=false
clean install
cd core/cocoon-webapp
mvn jetty:run-exploded -Dorg.apache.cocoon.mode=dev
I have had problems lately with that an avalon-framework-4.0.jar (from
2002!) is included in target/cocoon-webapp/WEB-INF/lib. It shadows the
Avalon framework 4.3 jars that Cocoon depends on and give a stack
trace similar to yours. Remove the faulty jar and try to run Cocoon
again.
I don't think this is the issue, since I see only two Avalon JARs, both
4.3 (avalon-framework-api-4.3.jar, avalon-framework-impl-4.3.jar).
Yes, I found out (by building with -X) that it is the batik block that
include the faulty avalon jar. And I had added the batik block my self
for testing purposes.
Some other points: jetty:run-exploded seem to do some unnecessary
extra work compared to jetty:run. Use the -e switch for jetty:run so
that you get the whole stack trace. Otherwise it is very hard to see
what is the problem.
Here you are, Sir:
Great ;)
[INFO] [jetty:run]
...
file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-deployer-plugin-classloading.jar,
This is strange, I don't have this jar on my class path. It is probably
a leftover from a build without the
-Dmaven.war.shieldingclassloader=false switch. Try a "mvn
-Dmaven.war.shieldingclassloader=false clean install" in the cocoon-webapp.
Actually a "mvn war:exploded" is even better as it is much faster
(doesn't build the war file), and doesn't call the deployer.
...
Caused by: java.lang.RuntimeException: Cannot invoke listener
[EMAIL PROTECTED]
at
org.apache.cocoon.maven.deployer.servlet.ShieldingListener.invoke(ShieldingListener.java:181)
at
org.apache.cocoon.maven.deployer.servlet.ShieldingListener.contextInitialized(ShieldingListener.java:204)
at
org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:441)
And here we can see that shielding classloader seem to be called anyway.
Probably the web.xml is patched to use the shielding stuff after an
earlier build.
The next question is of course why the shielding classloader doesn't
work in some environments. It works for me (jdk1.5.0_06, Windows XP).
/Daniel
