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