Re: Jini client inside Tomcat - FilePermission required to unmarshall a service item
Michal Kleczek <[email protected]> Thu, 3 Jan 2008 09:43:38 +0100
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
On Wednesday, 2 of January 2008 20:39:50 Peter Jones wrote: [snip] > > With the disclaimer that I'm no Tomcat expert, I think that its > WebappClassloader should execute the specialized piece of its > findClass override within a doPrivileged block that restores some > previous (consistent) access control context, for the same reason that > its superclass java.net.URLClassLoader's findClass does the same > thing: because lazy class loading can be triggered when there are > arbitrary restricted protection domains on the stack. If your servlet > had explicitly loaded the interfaces (and any other dependent types) > first-- like reflectively using Class.forName-- I suspect that this > access control exception would not occur, because the loadClass > invocation would be satisfied through the loaded class cache and never > get to findClass. But these permission requirements should not depend > on such order of operations. > > (As far as one web application being able to load classes from > another, it would presumably need a reference to the other's class > loader, which should not be available without a permission check.) > > This seems similar to the following bug that was filed against Tomcat > 5.0.19: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=28256 Read the bug report and it seems that's exactly the case (I didn't describe it in the original post to make it simpler). PreferredClassLoader loads interface classes successfully using codebase annotation but then Proxy.getProxyClass() fails with ClassNotFoundError because it cannot load dependent types (I guess for some reason proxy class is defined by WebappClassLoader). I'll try you solution (although it seems ugly) - preloading needed classes. > > by the author of the jiniservlet project[1]. It appears to have been > closed as not "relevant" given some planned refactoring, but as far as > I can tell the described issue still applies to the 6.0.14 version's > WebappClassloader. > > -- Peter > Thanks, Michal -------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to [email protected]