Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4AD86531.2020103@zeus.net.au>
Date: Fri, 16 Oct 2009 22:21:05 +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>
In-Reply-To: <caf30e2a0910152206r718c91b8qa6a593c01b474b82@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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> wrote:
>   
>> On Thu, Oct 15, 2009 at 11:53 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>>
>>     
>>> It may be possible to segregate OSGi modules, into separate ClassLoaders
>>> using bytecode dependency analysis and by capturing OSGi metadata.
>>>       
>> Unfortunately, this is harder than you might think. OSGi metadata
>> provides a set of constraints, but often there are multiple solutions
>> to those constraints, and sometimes the framework is not capable of
>> resolving those constraints even if there is a solution available,
>> since exhaustive checks are too expensive for large applications. What
>> I am trying to say is; Being able to figure out how a particular
>> framework implementation has wired up the class spaces, just by
>> looking at the metadata is impossible, and likewise with bytecode
>> dependency analysis.
>>     
>
> One more thing, it even depends on how the OSGi framework is started,
> since some packages may be exported from the classpath by the
> framework, and on top of that there is bootclasspath delegation
> throwing a big wrench into the heap of problems.
>
>
> Cheers
>