Summary: | request and session methods cannot be accessed by reflection in security mode | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | Will Glass-Husain <wglass> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 5.5.15 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | other |
Description
Will Glass-Husain
2006-10-16 11:50:32 UTC
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. |