Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4ADBA764.7070200@zeus.net.au>
Date: Mon, 19 Oct 2009 09:40:20 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Separating out RMIClassLoader dependencies
References: <4AD5FF60.2070207@wonderly.org>
	 <caf30e2a0910141941i7cea75fv780587ffc2e23fa5@mail.gmail.com>
	 <4AD69CBA.1050906@zeus.net.au>
	 <caf30e2a0910152204g413646daq787ad35f5d670d7e@mail.gmail.com>
	 <caf30e2a0910152206r718c91b8qa6a593c01b474b82@mail.gmail.com>
	 <4AD86531.2020103@zeus.net.au>
 <caf30e2a0910162040w55d65716g1af64c99921646f0@mail.gmail.com>
 <4ADBA6B7.90506@zeus.net.au>
In-Reply-To: <4ADBA6B7.90506@zeus.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ignore this message, it was sent during drafting.  The real message will 
follow.

Peter Firmstone wrote:
> Thanks Nic for your comments, pls see reply below.
>
> Niclas Hedhman wrote:
>> A big chunk of your bundle analysis already exist in a widely used OSGi
>> tool, named BND. Most OSGi developers use it, since it is near 
>> impossible to
>> create the metadata by hand, especially the "uses" constraint.
>>   
> Definitely agree, quite useful for eliminating syntax errors.
>> But before that we spoke of figuring out how a particular implementation
>> wire up a random set of bundles. That is not predictable, nor does 
>> the OSGi
>> spec provides an API to find out. Well, kind of... If you have the 
>> loaded
>> class, you can ask from which bundle it came, but unfortunately the
>> StackElement doesn't give you the Class, only the class name, which 
>> isn't
>> enough.
>>   
> Bytecode analysis, can identify all method signatures, all fields, the 
> level of access, public, package private, protected or private.
>
> It can also identify the serialVersionUID for classes that implement 
> Serializable.
>
> In addition if a bundle is used, the Metadata in the bundle indicates 
> packages to be exported, which defines the publicly accessible API.
>
> This information can be stored in Static Mirror Objects, for each 
> bundle, package and class.
>
> It is also possible to support the Java Product Versioning 
> Specification, the difference being that there would be one 
> Classloader per package, instead of per bundle.  Public and Protected 
> Public Class API signatures and serialVersionUID's stored in class 
> mirror objects, would determine API compatibility.  Preference would 
> be given to compatible Package Implementations that had greater 
> version ID's.
>
> Since the Static Bytecode Anaysis would allow identification of API 
> signatures, most importantly a Packages Public API, Protected API and 
> Class serialVersionUID's, it allows comparison of API between 
> different package versions. - Package API.
>
> Special consideration has to be given to Package API that is shared 
> between multiple packages, lazy loading requires some thought too.  I 
> think all dependencies will have to be resolved prior to loading for 
> all packages.  Failed resolution would require a JVM restart, with 
> state persistence.
>
> It's possible to additionally support the Java Product Versioning 
> Specification, where maximum sharing of classes is desired, eg 
> globally visible classes, as this increases the number of classloaders 
> and reduces the probability that a Package API conflict cannot be 
> handled gracefully, considering the size and availability of OSGi 
> bundle repository's, the likelyhood isn't great, but it may be useful 
> where new software is undergoing rapid development and API revision, 
> where shared classes need to be persisted.
>
> Perhaps I should name the Mirror Interface, in Reflective Terms, 
> StaticMirror - to indicate it doesn't change, with implementations 
> such as ClassStaticMirror, PackageStaticMirror and BundleStaticMirror, 
> Mirror objects produced by analysis could be stored in a hash that 
> looks up packages by name.
>
> I was also thinking that for dependency resolution, I could have a 
> PackageDependencyMirror Object, which ClassLoaders could submit to a 
> codebase service for resolution of the latest compatible packages.  
> The required packages
>
>
>
>
>> But I agree with you that with Jini tech and OSGi's well-defined
>> classloading semantics one can do really cool stuff. Including 
>> getting rid
>> of some of the more troubling Jini aspects (codebase).
>>
>> -- Niclas
>>
>> On Oct 16, 2009 8:21 PM, "Peter Firmstone" <jini@zeus.net.au> wrote:
>>
>> Hmm, that sounds like opportunity.
>>
>> A dedicated codebase service has all the time in the world to burn 
>> processor
>> cycles on analysis, as its main task is simply serving up jar files over
>> networks.
>>
>> Bytecode analysis, identifies class, package and possibly module API, 
>> which
>> can be stored with the harvested metadata in mirror objects, one for 
>> each
>> class, package and module.  Optional Package metadata could be a 
>> potential
>> source of information too.
>>
>> Bundles, depend upon and export packages.  Once the API is identified 
>> using
>> bytecode analysis, fast comparison using mirror objects could identify
>> compatibility.
>>
>> This could be utilised in two ways:
>>
>> 1. As a check of backward compatibility for modules / packages over
>> different release versions, for substituting later compatible bundle
>> versions, if desired.
>> 2. When a dependency on a package only utilises a subset of that 
>> package,
>> the actual API requirements may still be satisfied, even though 
>> different
>> release versions of that package may not usually be interchangeable 
>> or fully
>> compatible.
>>
>> A module or bundle would exist within its own classloader, in the 
>> local jvm.
>>   The packages or modules upon which it depends could be made 
>> available from
>> other classloaders.
>>
>> Bundles could be uploaded to codebase services or a codebase service 
>> could
>> retrieve the bundles from designated repository's, perform analysis, 
>> then
>> make the bundles available in a location independent manner, to prevent
>> codebase loss and allow for redundant codebase services.
>>
>> Then all one need do is to upload application bundles to the codebase 
>> server
>> and register a service, the service and bytecode could be provided
>> independently, the codebase service can provide entire application 
>> bytecode
>> built on Jini services and other third party libraries.
>>
>> Have a look on springsource, there are many OSGi jar bundles available,
>> these are simply jar files with Metadata.
>>
>> Someone's done so much hard work already, why not ride the wave?  
>> There are
>> already support tools available to create application bundle manifests.
>>
>> The reason I'm considering bundles, is it reduces the number of 
>> classloaders
>> required, one per bundle as opposed to one per package.  One cannot 
>> rely on
>> standard java Package meta data to exist in jar files.
>>
>> ********This doesn't require an OSGi framework.*********
>>
>> http://blog.springsource.com/2008/02/18/creating-osgi-bundles/
>>
>> http://www.springsource.com/repository/app/bundle?query=A
>>
>> http://www.springsource.com/repository/app/faq
>>
>> >From the website:
>>
>>
>>     What is the SpringSource Enterprise Bundle Repository?
>>
>> The SpringSource Enterprise Bundle Repository is a collection of open 
>> source
>> libraries commonly used for developing enterprise Java applications 
>> with the
>> Spring Framework. The repository contains jar files (bundles) and 
>> library
>> definition (".libd") files. A library defines a collection of bundles 
>> that
>> are often used together for some purpose (e.g. the "Spring Framework"
>> library). There are hundreds of bundles contained in the repository.
>>
>> The repository meets the following criteria:
>>
>>   * Every jar file in the repository is a valid OSGi bundle. Any jar
>>     you download from the repository can be deployed as-is into an
>>     OSGi Service Platform and the SpringSource dm Server. It can also
>>     be used as a regular jar file outside of OSGi.
>>   * Every bundle and library has full version information associated
>>     with it. The package export information for a bundle contains
>>     version information, and the package import information for a
>>     bundle contains full version range compatibility information.
>>   * The repository is transitively complete. The mandatory
>>     dependencies of any bundle are guaranteed to also be in the
>>     repository. Most of the optional dependencies of any bundle in the
>>     repository will also be present. The bundles listed in any library
>>     definition are guaranteed to be in the repository.
>>   * The repository is self-consistent. Before any artefact is uploaded
>>     to the repository, we verify that it can be installed, resolved,
>>     and started in an OSGi Service Platform (using the same profile as
>>     the SpringSource dm Server) alongside all of the other bundles in
>>     the repository.
>>   * The repository can be used from Ivy and Maven based builds.
>>
>> Cheers,
>>
>> Peter.
>>
>> Niclas Hedhman wrote: > > On Fri, Oct 16, 2009 at 1:04 PM, Niclas 
>> Hedhman <
>> niclas@hedhman.org> wro...
>>
>>   
>
>