On 10/07/2010 09:57 PM, Michal Kleczek wrote:
1. We annotate classes with an object implementing Module interface:
interface Module {
//methods copied from ClassLoading but there is no annotation argument
Class loadClass(...);
Class loadProxyClass();
}
This makes class loading pluggable - a service can designate it's own class
loading mechanism.
Note that the methods take boolean verifyCodebaseIntegrity argument. I think
it could be replaced by placing constraints on a Module.
I still need some convincing on providing remote classloaders.
Wouldn't we solve the problem 'trust by signing code', by modifying
ClassLoading.loadClass()?
We can have a URL handler for downloading code over any medium. We could
enforce only downloading code over trusted endpoints.
Once we have the jar in the localvm, we can verify the codesigning of
the classes. The only thing we need to do is to enrich the information
passed to verifyIntegrity() from codebase to code.
[or we could just have a caching url handler, and retrieve the code
again (but this time from the cache) in a IntegrityVerifier. This would
change nothing in the current river code. Any worms in this can?]
Gr. Sim
