On May 25, 2010, at 710PM, Peter Firmstone wrote: > This is a good question, which gets to the heart of the Jini's pattern. > > I think the proposed ClassLoader structure will benefit Rio, by enabling > increased API commonality and class sharing among Services and their clients. > > You can get around having to shutdown your jvm if you manage evolution of > your API interfaces correctly, set up a separate testing Registrar, to keep > new API interfaces out of your deployment, until they have stabilised.
Right now the JVM doesnt need to be shut down at all, services can be loaded with different versions, unloaded, etc ... I think you're making assumptions here. > > Classes, once loaded into a ClassLoader, cannot be garbage collected, but if > your API classes don't change there is no problem, when was the last time > ServiceRegistrar changed it's public API? Unlike Jini's platform classes > which are set in stone, new API classes can be introduced into older > environments. Right, which is why service implementations get loaded into their own class loader. You define the 'platform' as whatever that needs to be for your case. For Rio it includes requisite bootstrapping and infrastructure technology. For River it most likely just includes the River 'platform', or nothing at all. Consider ServiceStarter and the class loader created from that bootstrapping process. Please explain what is missing from that approach? Each service has it's own security policy. Why does this need to change? What and how does your approach improve on? To my eyes it seems overly complicated. > > Lets take Jini Platform services as an example, in Rio's ClassLoader tree > below, the Interfaces for the Platform services exist in the > CommonClassLoader, all classes in the CommonClassLoader are visible to any > class in any child ClassLoader below in the tree. > > Platform services can be shared freely among all child ClassLoaders. > > Now take Service-1CL and Service-2CL, lets imagine for a moment that these > two services both provide the same service, from different or the same node, > it doesn't matter, let's imagine now another node with the same ClassLoader > tree structure, which consumes these services. > > These services have their service interfaces bundled with their CodeSources, > both on the client and at the Service, lets say that Service-2CL provides the > same service, but has a different implementation. Now there's a client > service that consumes these services, performs an operation then discards the > service. > > Now which common API do the two service proxy's share? Common API? The service proxies dont share anything. They are each loaded from an implementation of RMIClassLoaderApi > This forces you to load both proxy's into the same ClassLoader, making their > implementations visible to each other and the client. Not so sure about that Peter. > > By separating the API into, in your case the CommonClassLoader, APIs are not added to the CommonClassLoader, and I would argue that it should not happen. You generally do not want to add classes into a class loader that does not get GC'd. > each with their own ProtectionDomains, all Services and clients in that node, > share the same API classes and can be isolated in their own ClassLoader's and > can have different implementations but share the same common API types. > > The client service-param.jar is for clients who create new implementations / > extend parameters in API methods, the Service server node will require these > classes to unmarshall the parameters. Client parameter classes will never be > granted permissions. > > I'll make up some separate ClassLoader tree diagrams showing the client node, > the service node and the relationships between remote ClassLoaders. > > Peter. > > Dennis Reedy wrote: >> If I understand correctly I think this is the crux of the issue. I dont >> understand why you need to load all API classes with the same class loader. >> FWIW, in Rio we handle the loading (and unloading) of services with the >> following structure >> (http://www.rio-project.org/apidocs/org/rioproject/boot/package-summary.html#package_description): >> AppCL >> | >> CommonClassLoader (http:// URLs of common JARs) >> + >> | >> + >> +-------+-------+----...---+ >> | | | >> Service-1CL Service-2CL Service-nCL >> >> AppCL - Contains the main() class of the container. Main-Class in manifest >> points to com.sun.jini.start.ServiceStarter >> Classpath: boot.jar, start.jar, jsk-platform.jar >> Codebase: none >> >> CommonClassLoader - Contains the common Rio and Jini technology classes (and >> other declared common platform JARs) to be made available to its children. >> Classpath: Common JARs such as rio.jar >> Codebase: Context dependent. The codebase returned is the codebase of the >> specific child CL that is the current context of the request. >> >> Service-nCL - Contains the service specific implementation classes. >> Classpath: serviceImpl.jar >> Codebase: "serviceX-dl.jar rio-dl.jar jsk-lib-dl.jar" >> >> Certainly not as sophisticated as OSGi (or what you are targeting), but it >> meets the requirements of allowing multiple service versions, applying >> security context per class loader using the same approach as >> ActivateWrapper, and allows the JVM to stay running. >> >
