On Tuesday 12 of October 2010 00:27:12 Peter Firmstone wrote: > Michal Kleczek wrote: > > On Monday 11 of October 2010 15:41:46 Peter Firmstone wrote: > >> What about the case where a Module depends on another Module? > >> > >> I'm guessing that was the intent. > > > > Actually - no :) > > > > There are two different things to consider: > > > > 1. Module dependencies (which I actually did not think about too much). > > Actually I'm thinking there shouldn't be any dependencies, other than > the Jini Platform and ServiceAPI, which has been used to obtain the > Module.
This is true as long as we have one special ClassLoader that loads ServiceAPIs. That is the case with current Jini and has its ramifications. Once you think about peer class loading model where different versions of the same class (even ServiceAPI class) can coexist you need Module dependencies. But let's not go there at this moment. I don't think there are many differences between our ideas - let me summarize them (at least how I understand them). 1. You want to issue a remote call to _retrieve_ annotations whereas I want to do that to _verify_ them. I think this is a problem since this way you cannot turn this stuff off altogether (for example for testing). 2. You want to automatically grant DownloadPermission to CodeSources you've just retrieved I think that is a problem since it means suppressing standard DownloadPermission checks altogether. I would say - just use standard PreferredClassProvider that does not do DownloadPermission checks. 3. You want to automatically grant GrantPermission(new DownloadPermission()) to new ClassLoaders And that is something I would like to be conditional - the client has to have a way to either allow or not allow a proxy to download more code without local verification. But it must be possible to say: "I've got a proxy from you and I trust you verified the code you are going to download to my address space - so I won't check this code by myself" Michal
