....
On 8 November 2012 10:51, Peter Firmstone <j...@zeus.net.au> wrote:
> 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?
>
>
Good discussion...
> Now that we have the opportunity, should we also reconsider functionality?
>
>
Maybe, I would say let's keep it simple, be clear about why we're doing
what we're doing and what we want to get out of it now. Then we can get
something into the codebase soon'ish.
> For example using another string annotation in MarshalOutputStream might
> allow selection from a list of providers in a mixed environment?
>
>
And given the above, we can add this sort of thing later as we wish.
> This might also allow a new provider to be downloaded on demand, provided
> it has sufficient privileges.
>
>
Cool indeed but why would this matter?
I don't want to be harsh but as a group we seemingly spend a lot of time
thinking about all sorts of cool things we could do given we've already
done this or that other thing.
How about we do a few small steps in some promising (like valuable to our
community not just individual developers' needs) directions and then see
what's what.
To do otherwise runs risk of having an even bigger, more complex to manage
and understand codebase with lots of configuration and customisation - to
what value?
We have meagre resources, we're very ambitious but we seem to undo the
horsepower we have by going very wide and very deep, is that good?
Thoughts?
>
> Peter.
>
>
