river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Maven repository Entry was Re: Codebase service?
Date Wed, 26 May 2010 02:28:37 GMT

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. 
>>  
> 


Mime
View raw message