river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kleczek <michal.klec...@xpro.biz>
Subject Re: Towards Internet Jini Services (trust)
Date Thu, 07 Oct 2010 19:57:48 GMT
I've spent a day on some thinking and prototyping and hopefully I got an idea.
Here is an outline:

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.

2. Before using a Module we prepare it using a ProxyPreparer - that way we 
make sure we trust the Module before letting it load classes

3. We have a default implementation of Module that delegates class loading to 
RmiModule implements Module {
  private String annotation;

4. There is a single instance of RmiModule called BOOTSTRAP that we use to 
load RmiModule class. This is implemented in:
RmiModule {
    static Module getModuleOf(final Class cl) {
         * RmiModule is equivalent of String annotation
         * so it should be available locally
        if (cl == RmiModule.class) {
            return getBootstrap();

        final ClassLoader loader = getClassLoader(cl);
        if (loader instanceof ModuleClassLoader) {
            return ((ModuleClassLoader) loader).getModule();


        final String annotation = RMIClassLoader.getClassAnnotation(cl);
        return annotation != null ? RmiModule.getInstance(
           annotation,getModuleTrust(loader)) : getBootstrap();

5. We use the above method in annotateClass and annotateProxyClass of our 

6. RmiModule can be verified by ProxyTrustVerifier. It's ProxyTrust 
implementation delegates TrustVerifier retrieval to:
public interface ModuleAuthority extends Remote {
    TrustVerifier getModuleVerifier() throws RemoteException;

7. We implement some helper functions that make it simpler to export a service 
and provide its clients with either third party ModuleAuthority or designate 
itself as a ModuleAuthority.

8. Before all this is implemented in PreferredClassProvider we have to cache 
association between a ClassLoader and a Module. It's implemented in RmiModule.

9. If we implement it in PreferredClassProvider our ClassLoaders can keep a 
reference to associated Module

10. If we implement it in PreferredClassProvider we can have different 
ClassLoaders for the same annotation but different ModuleAuthority - that would 
actually allow us to grant permissions to Modules - before that two different 
Modules with the same annotation are going to share permissions.

I've attached a prototype implementation (note - it is a proto-proto-
prototype) so that you guys can verify if you have some spare time.
Don't know if mailing list server allows attachments.


On Tuesday 05 of October 2010 16:48:22 Michal Kleczek wrote:
> On Tuesday 05 of October 2010 16:36:47 Gregg Wonderly wrote:
> > On 10/1/2010 12:38 PM, Michal Kleczek wrote:
> > > When I think about it some more - the below idea is not enough and we
> > > need a more general solution.
> > > How about class annotation not being a String but rather an object... I
> > > have to give it some more thought.
> > 
> > There are been some thought and discussion about doing this.  It is
> > possible, but the problem becomes that if you send an object with the
> > annotation, then how does the receiver unmarshall that object?  Is that
> > object something that everyone knows about ahead of time?
> My line of thought was - yes. It would have to be something similar to
> ProxyTrust - a factory to receive an Unmarshaller.
> I haven't really given it enough thought.
> But I am more and more convinced that doing that at the higher (proxy
> preparation) level - as I described it earlier - could actually be enough.
> Michal

View raw message