Hi Barbara / Robby,

thanks both of you for the quick reply - and sorry for originally
posting my question twice!

Sadly, your hints didn't help me solving the issue.

@Robby:
- i think it's not a webapp context issue - tomcat refuses to start
the wepapp, so no context (neither the webabb nor the block) is
accesible;
- the block dependency is declared in the pom, and maven doesn't
complain on "mvn package", so i think this isn't the problem, too;
- how to disable the reloading classloader? I'm not sure, but after
reading 
http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1297_1_1.html
i think i have to enable it explicitly, so i don't know ho to disable
it after i don't hae such a dependency declaration in my webapp
pom.xml.

@Barbara:
Inserting the filter and the filter-mapping as proposed didn't change
anything - tomcat still refuses to start that webapp, still the same
stacktrace appears. I've checked the content of the web.xml in the
packaged war to be sure that the change shows up there. Are there any
other changes to apply to the standard webapp code?

I tried the adding the filter to web.xml with both my own test app
(involving a block, as described in my first post) and the
"cocoon22-classic-webapp" from the cocoon whiteboard - both with the
same result (Jetty works, Tomcat doesn't, same NoClassDefFoundError),
both with and without the proposed filer/filter-mapping.

mvn -v displays (just if it's a matter of the JRE / Tomcat version):
Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_20
Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux" version: "2.6.31-22-generic-pae" arch: "i386" Family: "unix"


florian

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Reply via email to