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: Cooperative Distributed computing - Versioning over time - Container Metadata.
Date Tue, 20 Oct 2009 02:58:09 GMT

If we were able to utilise OSGi bundles, I can't then see why there 
couldn't be a way of setting up some kind of Bridge or Facade pattern to 
interoperate with OSGi.  I'm only hypothesising, I don't have any 
particular implementation in mind. The advantage here would be the 
possibility of using common bundle code for both environments.

Peter Firmstone wrote:
> 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
>      compatibility.
>   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
>      Classloaders.
>   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 continued.
> 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.
> Regards,
> Peter.
> 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