Apparently the latest version (5.5.20-2etch1) has additional security headaches features which prevent wicket from functioning properly out-of-the-box:

• First of all, there’s still an (as-yet-unsolved) mystery around why I couldn’t get Wicket to start up as a filter. Just the mysterious “ERROR: filterStart” which makes me want to feed Tomcat to angry lions. Worked around it by using Wicket in Servlet mode instead.
• Tomcat’s juli.jar can’t access WEB-INF/classes/logging.properties. Fixed (in sledgehammer-like way) by adding “permission java.security.AllPermission;” to /etc/tomcat5.5/policy.d/03catalina.policy, in the Juli section.
• Tomcat security prevents webapps from accessing all sorts of features and methods by default, including wicket.properties, methods inside shipped jars, etc. Not being a Tomcat expert, and trusting the innate security of the server and millions of lines of third party code (i.e. I’m an idiot) I again just popped a java.security.AllPermission; in appropriate spots in /etc/tomcat5.5/policy.d/04webapps.policy. Let the flames commence!

If Tomcat was a little more helpful in its error messages, this would never have been so painful. Jetty has always run my Wicket apps without complaint (though I’ve never tried the official Debian Jetty packages – maybe they’re crippleware secure too?).

The only reason I use Tomcat at all is the remote management and deployment features, which are well-supported by Cargo. Now that these issues are out of the way (mostly) I can take another few steps towards my dream of a seamless, fire-and-forget, auto-deploying, smoke-tested, pluggable and modular web app deployment system.

Oh, and have I mentioned recently how much I LOVE IInitializer?

Bless you, Wicket. Bless you.