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]