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

Hi,

On Thursday, 3 of January 2008 19:47:38 Peter Jones wrote:
> 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.

In my case there are two interfaces
Int1 - used by the client
Int2 extends Int1, Administrable, Remote - implemented by the service
and the class
DataObject used as a return value from one of the Int1 methods.

So when reggie proxy unmarshalls the service proxy Int1 is already loaded by 
WebappClassLoader. Int2 gets loaded by PreferredClassLoader from the codebase 
annotation. Proxy.getProxyClass() is called by PreferredClassProvider from 
outside any privileged block and since Int1 classloader (WebappClassloader) 
is used to load DataObject class the permission check fails and 
ClassNotFoundError is thrown.

>
> > I'll try you solution (although it seems ugly) - preloading needed
> > classes.
>
> Admittedly it would be an ugly workaround.

I thought about wrapping a WebappClassloader with my own one and setting it as 
a context classloader when creating LookupDiscoveryManager but now - when (I 
think) I understand what's going on - I'm pretty sure it won't work. 

>
> -- Peter

Thanks for help,
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]