river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Cooperative Distributed computing - Versioning over time - Container Metadata.
Date Mon, 19 Oct 2009 13:01:46 GMT
Let me put it another way:

I want to work toward a cooperative distributed computing platform using 
Java & Jini / River, continuing from  where Sun left, using lessons learned.

   1. I'd like to set up a class loader framework building on
      classworlds, to segregate incompatible class versions with the
      same name, while allowing compatible implementations to
      interoperate, based on Class loader visibility.
   2. I'd like to utilise the ASM bytecode library to perform static
      analysis on bytecode to identify Package & Class API to determine
   3. I'd like to solve the lost code base problem using codebase
      services combined with the suggested Class loading framework.
   4. I'd like to use codebase servcies to provide codebase proxy's for
      often disconnected clients.
   5. I'd like to allow bytecode to evolve organically by taking
      advantage of the flexibility of binary compatibility.
   6. I'd like some metadata to identify at the minimum ,Package
      Versions, I could generate checksums based on Package API, however
      this wouldn't identify which version is the latest, only which
      Package implementations can substitute another's API  where those
      packages share the same name. Or identify packages with the same
      name that are incompatible and segregate these in separate
   7. If possible due to concerns about the performance impact of many
      Classloaders, group some packages together when the author doesn't
      intend those packages to evolve separately.  Eg libraries.
   8. I'd like to make it possible to transfer class version and package
      version information with serialized object instances for
      compatible re-instantiation with the latest evolution of
      compatible classes.  All suggestions are welcome.

Does anyone have any suggestions for suitable existing formats for 
Containers with Version Metadata that might be utilised?   

If so what issues are there to be aware of?  What are the arguments for 
and Against?

Note, I'm aware of the existing Java Version Spec that applies to packages.

I believe I made the mistake of suggesting a solution without properly 
formulating or posing the problem, my apologies for any confusion this 
might have caused, I should have raised a new thread / topic,   In the 
original thread, Gregg is looking at classloader dependency issues 
implementing a plugin for Netbeans to make River more accessible to IDE 
developers, please feel free to make suggestions, we need your help.

I made a suggestion earlier to utilise the OSGi bundle metadata 
specification, these are ordinary jar files with package version, 
exports and dependency metadata.  They are otherwise ordinary plain old 
jar archives,  quite useable as a jar file containing java class files 
that can be utilised without  the OSGi framework, which is what I was 
suggesting. I attempted to imply that the exported packages could have 
their API identified and shared in a compatible manner with other 
packages, using Class loader isolation perhaps this is not a suitable 
solution due to the confusion that it would cause with developers 
expecting an OSGi implementation, utilising OSGi service interfaces.  If 
this format was to be utilised, it might have to be renamed, to River 
Codebase Bundles (for uploading to codebases) whilst sharing the same 
format to avoid confusion.   It might be a subset of the OSGi bundle 
format, such that OSGi bundles, like those on the Spring Source 
Repository could be utilised.  It might also be a component in an 
eventual Container spec, if we can sort that out.  Gregg has asked for 
container suggestions more than once, I'd like to see that conversation 

If this solution was adopted, the dependency version metadata (Import 
Package) in the bundle would be noted, considered a minimum version as 
per the OSGi spec, but a later version would be utilized if it were 
found API compatible.  However additional protection by static analysis 
would guarantee that a later version that wasn't API compatible would 
not be utilised. The reason I'm considering  this compromise is that a 
bundle author cannot know in advance that later import packages will be 
compatible, hence Static Analysis can verify API compatibility.  It is 
still possible for identical named classes to be loaded in the same jvm, 
in another classloader, this might occur if an earlier package version 
already exists but doesn't satisfy the Import Package version criteria; 
it wont be used as it is earlier than the minimum required version.  The 
Classloader responsible for the bundle would keep a copy of the  
metadata available while it remains loaded, it would not utilise the 
OSGi interfaces to access the metadata.  I envision Immutable Mirror 
Objects that can be transferred with marshalled instances and utilised 
for API compatibility checking.  The Mirror objects would be created by 
a codebase service and stored in memory by the Classloader that download 
the class bytecode (River Bundles) being Mirrored,  the mirror objects 
would contain the metadata from the bundle as well as the API, the 
mirror objects would be used by the classloader to determine which 
packages to export as well as check for import package compatibility, 
and by other Classloader's for compatibility.  If no compatible packages 
are found loaded then the codebase services would be consulted, the 
import package mirror object would be submitted to the codebase services 
to locate a compatible package or bundle.

In principle, if this is still objectionable, I'm happy to create an 
implementation utilising another container or bundle format that 
satisfies the requirements, provided that one is recommended.  This list 
does have a history of heated debate regarding OSGi and Jini, I'd like 
to avoid any such unproductive arguments if possible.



Niclas Hedhman wrote:
> On Mon, Oct 19, 2009 at 7:40 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>>> Thanks Nic for your comments, pls see reply below.
> I think we have diverged and discussing different things.
> Some time ago, it was said that the classloader of a class could be
> retrieved by calling a static method. I have tried to point out that
> this is fairly "impossible" in OSGi without collaboration with the
> OSGi framework implementation, as multiple (even fully compatible, or
> even exact same versions) instance of the same classes can be present
> in different class spaces within the OSGi framework, and which package
> got resolved to which bundle (and hence the classloader) is an
> implementation detail in OSGi. There is no theory around that fact. I
> am speaking of "locating a classloader of an existing class already
> present", and not how to locate one externally to the JVM and OSGi
> framework.
> See the difference?
> So if ClassA wants to load an implementation of InterfaceB, then that
> implementation must be chosen from the class space that ClassA and
> InterfaceB belongs to, and not only that it implements
> InterfaceB+constraints.
> Cheers

View raw message