RiverClassLoaderSPI

[Peter Firmstone]

I've been quite busy lately so haven't been able to contribute much to 
discussion.

However I've some thoughts on RMIClassLoaderSPI / RiverClassLoaderSPI / 
CodebaseAccessClassLoader and finally had some time to write them down.

Notably RiverClassLoaderSPI solves the issue of the implementation 
having to be on the class path (system ClassLoader), instead the 
ContextClassLoader is used to resolve the service provider.

public abstract class RiverClassLoaderSpi
{
  
   public abstract Class<?> loadClass(String codebase, String name, 
ClassLoader defaultLoader)
       throws MalformedURLException, ClassNotFoundException ;

   public abstract Class<?> loadProxyClass(String codebase, String[] 
interfaceNames, ClassLoader defaultLoader)
       throws ClassNotFoundException, MalformedURLException ;

   public abstract String getClassAnnotation(Class<?> cl);

   public abstract ClassLoader getClassLoader(String codebase)
       throws MalformedURLException, SecurityException ;

}


Would it be clearer if we call it RemoteClassLoaderSPI?

Because it's an abstract class it can't inherit from ClassLoader, 
perhaps we could call it RemoteClassResolverSPI.

Or perhaps MarshalClassResolverSPI?

Now that we have the opportunity, should we also reconsider functionality?

For example using another string annotation in MarshalOutputStream might 
allow selection from a list of providers in a mixed environment?

This might also allow a new provider to be downloaded on demand, 
provided it has sufficient privileges.

Thoughts?

Peter.