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.
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.
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? This forces you
to load both proxy's into the same ClassLoader, making their
implementations visible to each other and the client.
By separating the API into, in your case the CommonClassLoader, 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.
