Methods on HttpServletRequest and HttpSession cannot be accessed by reflection when running under security mode. (a permission error will result). This is a problem when running applications serving pages with Velocity, as the Velocity syntax $request.session.d uses reflection to call the methods getSession() and getId() and hence will fail with the stack trace below [1]. To make this work successfully you need to put several permissions in catalina.policy [2] This seems at odds with a philosophy that using the core servlet api should not require internal tomcat packages to be exposed to the webapp. Additional references: Velocity JIRA issue http://issues.apache.org/jira/browse/VELTOOLS-66 Mailing list discussion with user http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg17060.html Tested with: Tomcat 5.5.15 Java build 1.5.0_06-b05 [1] java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.connector) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPackageAccess(Unknown Source) at java.lang.Class.checkMemberAccess(Unknown Source) at java.lang.Class.getMethods(Unknown Source) at org.apache.velocity.util.introspection.ClassMap.getAccessibleMethods(ClassMap.java:262) at org.apache.velocity.util.introspection.ClassMap.populateMethodCache(ClassMap.java:155) at org.apache.velocity.util.introspection.ClassMap.(ClassMap.java:66) at org.apache.velocity.util.introspection.IntrospectorBase.createClassMap(IntrospectorBase.java:132) at org.apache.velocity.util.introspection.IntrospectorBase.getMethod(IntrospectorBase.java:116) at org.apache.velocity.util.introspection.Introspector.getMethod(Introspector.java:108) at org.apache.velocity.runtime.parser.node.PropertyExecutor.discover(PropertyExecutor.java:96) at org.apache.velocity.runtime.parser.node.PropertyExecutor.(PropertyExecutor.java:54) at org.apache.velocity.util.introspection.UberspectImpl.getPropertyGet(UberspectImpl.java:192) at org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:140) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:324) at org.apache.velocity.Template.merge(Template.java:259) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.performMerge(Unknown Source) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.mergeTemplate(Unknown Source) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest(Unknown Source) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) [2] grant codeBase "file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-1.4.jar" { permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.connector"; permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.session"; permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.core"; }; grant codeBase "file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-tools-view-1.2.jar" { permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.connector"; permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.session"; permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.core"; };
I can't see a way of relaxing the security constraints to allow reflection on the *Facade objects without opening access to the entire package. It might be possible to move all the facades to their own package and then allow access to that package but I haven't investigated the implications of this. I also want to try to reproduce this with a simple test case to see if I can find an alternative way of doing the reflection that doesn't generate the security exception.
Moving the facade objects to their own package seems the simplest approach to me. Can't think of any downside -- since they are internal implementations there shouldn't be any compatibility issues.
Velocity should not try to use reflection on tomcats internal classes. If you do the same on the correct interface classes, you get no security violation. Unfortunately mapping the objects to the corresponding interface classes doesn't look very nice. Have a look at my comment in: https://issues.apache.org/jira/browse/VELTOOLS-66
Closing as INVALID based on Rainer's investigations.