On Jan 3, 2011, at 1239AM, Peter wrote: > That's similar to my thinking. > > The reason class loaders are of interest, is the jar archives we produce > affect our ability to segregate these classes into separate class loaders at > runtime.
AFAIK, the current distribution provides this already with ServiceStarter. > > If we put platform implementation classes into a child class loader, they're > no longer visible to proxy's, services or clients, it improves security and > prevents implementation changes breaking application code. > > The platform will need a reference to the implementation class loader in > order to instantiate objects. Probably obtained from a static class method. I'm not sure this is the case. Currently (using ServiceStarter), a service classloader (sCL) created for a service that delegates to the classloader used to start the JVM. The JSK provided services include jsk-lib.jar in their Class-Path manifest, so the 'platform' is loaded is the same classloader that loads the service. Once that sCL is created, the current thread's context classloader is set to the sCL and the service is loaded. Perhaps it may help to take a look at NonActivatableServiceDescriptor.create()? Dennis
