incubator-river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Mon, 27 Jul 2009 19:51:18 GMT
Peter Firmstone wrote:
> Hi Gregg,
> 
> I hear what your saying.
> Can I share some thoughts?
> 
> An Object's Class Type is the fully qualified class name + the 
> originating ClassLoader.

Once it is live in the VM, it is, but until that time, it's the source "jar" 
that represents the "type" because versioning is expressed there.  Michael 
Warres' paper indicates this, and I think you grasp that concept.  The 
classloader is just a software representation of the contents of the Jar file.

> HTTP codebase's are part of the problem, the URLClassLoader is fixed in 
> the object's Type (class identity), which may change over time.  Michael 
> Warres addressed this problem by creating a dynamic codebase service 
> where the URL was a cryptographic hash of the jar file (stored data) 
> identity.

The codebase, if not designed with versioning as part of the expression of it, 
is the root cause of missing "version" information.  It's still possible to 
create multiple class loaders using the same URL at different times, and have 
those classloaders do things like store the Jar locally, be long lived and be 
resurrectable across processes etc.

The Hash is a good solution, but does require some tooling for service 
deployment and perhaps a container mechanism to make easy use of, but it's still 
possible to use it manually with just a few tools.

> Michael made a presentation on Service based codebases, apparently not 
> much code was required to implement it.  We cannot directly copy the 
> code (interfaces etc) from the presentation due to copyright, although 
> we can produce functionally equivalent code.
> 
> http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
> 
> See also River-316
> 
> So the dynamic service based codebase could move around, and be offered 
> redundantly.

I wrote a protocol handler which would be used as

-Djava.protocol.handler.pkgs="codebase:service-dl.jar codebase:jsk-dl.jar"

which would do service lookup, and then ask services "do you provide 
service-dl.jar" and "do you provide jsk-dl.jar".  It would then get the jars 
from one of the services that answered yes, and return the URLConnection to the 
downloaded jar as a "file:" URL.

I didn't ever deploy anything using this, because I really don't run into 
problems of services working but the codebase provider not working, very often, 
if at all in production.  It happens occasionally in development.

> In addition, we could update/upgrade/replace the Hierarchical based 
> PreferredClassLoader relationship with a more flexible 
> DynamicClassLoader based on ClassWorlds to segregate incompatible class 
> packages while granting compatible classes the ability to communicate.  
> There is BSD licensed code that we could build on:
> 
> http://classworlds.codehaus.org/  ClassWorlds has some very elegant 
> simple models (easy to code & use) that may help us.

I'll try and look at ClassWorlds.  The PreferredClassLoader provides one 
mechanism that allows the "implementation" vs "contract" aspect of a 
class/interface to be specified and thus where it is loaded from, controlled. 
The fact that it defers to its "parent" when "not preferred" just means that we 
could do anything with the rest of the loading process which should really just 
leave 2 types of classes, the "JVM classes" and the "contract classes".  Both 
might have version related details.  The "JVM classes" would imply something a 
bit harder to "solve" at runtime.  But, the "contract classes" versioning could 
be specified by some additional information in the PREFERRED.LIST perhaps.

Understand when I said "parent" above that I'm not suggesting that there should 
be a linear hierarchy of ClassLoaders.  Just that the parent is the next place 
to defer to.

>> From the above website: "The |classworlds| model does away with the 
>> hierarchy normally associated with ClassLoaders.  Instead, there is a 
>> pool of ClassRealms 
>> <http://classworlds.codehaus.org/apidocs/com/codehaus/classworlds/ClassRealm.html>

>> which can import arbitrary packages from other ClassRealms. 
>> Effectively, |classworlds| turns the old-style hierarchy into a 
>> directed graph."
> 
> One might give a library its own ClassLoader in each JVM for instance, 
> then we could make that library available to the applications / services 
> that depended upon it. A later version of that library would have a 
> separate ClassLoader so that "Jar hell" or "Classpath Hell" (standalone 
> JVM talk) or its distributed equivalent "Class Type Hell" or 
> "ClassLoader Hell" are avoided (unfair: ClassLoaders are a blessing in 
> disguise, they add another dimension to namespaces).

One thing that I think makes sense is to put together some trial version 
management bits of code.  The mechanics are the important part to "get right" 
first, and then we can survey what works and think about how to access it and 
put together automatic mechanisms where possible (the invocation layer would 
allow this to happen seamlessly for version "upgrades", not so sure about 
downgrades).  Factory style methods could be used in iterative services where 
things are "loaded", "processed" and "stored".

I think this "space" already has had a lot of different things evaluated and 
things like "classworlds" show that some "code" has gelled in many places that 
provides solutions to various parts of the problem space.

Gregg Wonderly

Mime
View raw message