Re: Jini client inside Tomcat - FilePermission required to unmarshall a service item

On Thu, Jan 03, 2008 at 09:43:38AM +0100, Michal Kleczek wrote:
> 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

Oh, so the stack trace from your initial message does not correspond
to the exception causing the failure (so the reggie code on that stack
does actually have the necessary permissions)?

I believe that the exact case behind the above bug report involved a
normal class, not a dynamic proxy class, and I'm not quite sure how
the bug case maps to a dynamic proxy class case-- perhaps it involves
indirect inheritance through a private interface?  (The actual failure
stack trace would help.)

> (I guess for some reason proxy class is defined by
> WebappClassLoader).

If it has a codebase annotation, I would expect it to be defined by
the PreferredClassLoader for the service.

> I'll try you solution (although it seems ugly) - preloading needed
> classes.

Admittedly it would be an ugly workaround.

-- Peter

--------------------------------------------------------------------------
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]