https://issues.apache.org/bugzilla/show_bug.cgi?id=41509
--- Comment #4 from Steve Loughran <ste...@apache.org> 2009-04-24 08:41:28 PST --- It is a shame that this is a WONTFIX as it may stop Jasper working with RMI Java6+ JVM. One needs security for its classloader to work, the other bangs up against a changed semantics of Sun's JVM. It is also hard to see how this can be fixed in Jasper. Here is what the Java6 javadocs have to say on the topic: "Applications are discouraged from calling this method since this operation may not be supported by all policy implementations. Applications should solely rely on the implies method to perform policy checks. If an application absolutely must call a getPermissions method, it should call getPermissions(ProtectionDomain). The default implementation of this method returns Policy.UNSUPPORTED_EMPTY_COLLECTION. This method can be overridden if the policy implementation can return a set of permissions granted to a CodeSource." What would happen if Jasper could recognise the situation in which there was a read-only policy and skip trying to set permissions -or could it perhaps check to see if the permissions were already granted by the security manager before trying to set them? See also http://mail-archives.apache.org/mod_mbox/incubator-river-user/200810.mbox/%3c20081015181649.gb4...@east%3e -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
