I still don't get it - we don't have to muck around with container or application permissions *now*, and we run with almost every standard Java EE container (except Oracle), that I can tell.
Janne -- we run now in containers, that's true. But not when a security manager is installed. JSPWiki won't run in Tomcat if you enable the "-security" option. It never has.
I also don't understand why you need all the cloak-n-dagger, since the code is running in a non-privileged container, which is already in sandbox, on a computer, which is trusted. It sounds like awful lot of design overkill to me.
I agree with you that this does seem like overkill. But most Java containers are NOT, in fact, running in a sandbox because the security manager isn't on. There's nothing stopping my Tomcat production server, for example (which doesn't run with a security manager) from deleting everything in the home directory of the runtime user.
Reflection?
Reflection enables you to run methods you don't normally have access to, like private methods. That's why it's something that requires privileges (...when running under a security manager)
That, of course, means that Stripes won't run...
It might, but it depends on how well isolated Stripes' reflection code is. If it's bracketed by doPrivileged blocks, then it's no problem; we'd just need to make sure that Stripes.jar was granted the appropriate privileges in our pro-forma security policy.
/Janne
