river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Tue, 28 Jul 2009 09:49:53 GMT
Hi Gregg,

Comments inline.

Gregg Wonderly wrote:
> 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.
I'd like to make versioning finer grained than that, at least for 
applications, I'd like to segregate at the Package level, many class 
files don't change once applications mature,  for Library's it makes 
better sense to have a coarse grained versioning mechanism.
>
>> 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.
I'm really keen to see Michal's code that may be on offer from XPro, as 
it supports a P2P mechanism.  However please upload.
>
>> 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".
Have a look at River-316, I've uploaded, code with plenty of comments & 
Javadoc.
>
> 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.
I'm interested in ClassWorlds, to me, its a poor man's Subprocess API 
(shame that never eventuated maybe it will in Harmony?), it would allow 
isolation between packages, and libraries, limiting classpath scope to 
only that which is requried.

>
> Gregg Wonderly
>
Cheers,

Peter.

Mime
View raw message