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: <4B05DE2F.30004@zeus.net.au>
Date: Fri, 20 Nov 2009 10:09:19 +1000
From: Peter Firmstone <jini@zeus.net.au>
Organization: Zeus Project Services
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: River & OSGi
References: <4AF391EE.70006@zeus.net.au>
	 <0D2AF945-B7BF-4DA9-9D27-557F3D296460@topiatechnology.com>
	 <4AF40932.5070502@zeus.net.au>
	 <004F9331-EED2-4895-AA9A-E413FBEDB716@topiatechnology.com>
	 <4AF4D950.1000102@zeus.net.au>
	 <17F527F6-22B6-4C54-B7E3-E8FC9F645C28@topiatechnology.com>
 <e736790911062111o2bc4e991mfc3afed4f1fca92b@mail.gmail.com>
 <4AF65C5D.3070506@zeus.net.au>
 <BB1EB5CC-A54F-4A03-8215-1CE027A09F69@gmail.com>
 <4AF76B20.7010007@zeus.net.au>
 <EEC576FD-8AD9-45A3-B125-18C2736115D2@topiatechnology.com>
 <4B037920.5010501@zeus.net.au>
 <8D43BD10-116C-468A-BA09-ED2AC566029F@topiatechnology.com>
 <4B03F459.8010108@zeus.net.au>
 <3388C4E6-1809-4C25-9015-E231EE25DB52@gmail.com>
 <4B0494DB.8090508@zeus.net.au>
 <75174F30-B2E9-4616-8623-2ECDF5BF8776@gmail.com>
 <FE340D2A-E1E1-4824-A78F-8141FAA7F3DB@topiatechnology.com>
 <93DA9D69-0F6F-4FC1-93C6-6183CD2A4018@gmail.com>
 <4B059F45.1090808@zeus.net.au> <4B05AC44.1070401@zeus.net.au>
 <9D982B9E-369C-40E4-BFC9-610DE9280188@topiatechnology.c
 om>
In-Reply-To: <9D982B9E-369C-40E4-BFC9-610DE9280188@topiatechnology.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

That's the right question.

    * Set up Apache River for Pervasive Computing, by laying foundations
      that:
          o Make it possible to lookup the correct latest compatible
            bytecode for marshalled object instances using the publish,
            find, bind pattern.
          o Enable sharing of objects between different applications
            based on common domain object libraries, enable those
            libraries to evolve unconstrained by backward compatiblity
            without loosing the object data when the bytecode drops
            backward compatibility due to refactoring.
          o Make node bytecode upgrades seamless for applications.

For some background see the following Papers:

The paper on Classloading issues by Michael Warres on River-316

Or at:

http://research.sun.com/techrep/2006/smli_tr-2006-149.pdf

The Paper on Project Neuromancer, highlighting problems with Jini and Java.
http://research.sun.com/techrep/2007/smli_tr-2007-162.pdf

My latest heading is inspired by Tim Blackman's research on classloader 
trees.  No paper was released for this, however we have some of the code 
Tim used in com.sun.util.tools.classdepend

Regards,

Peter.

Michael McGrady wrote:
> What is the overall goal?  What does success look like?
>
> Mike
>
> On Nov 19, 2009, at 12:36 PM, Peter Firmstone wrote:
>>
>> I'm having a discussion about Classloader separation, modularity 
>> (OSGi), and binary compatibility within the local JVM, sharing of 
>> bytecode when it should be, eg shared domain objects, marshalled, 
>> unmarshalled or otherwise.  I'm trying to find a solution to this 
>> problem of ensuring compatible packages are loaded within each jvm on 
>> separate nodes participating in a djinn, I can see that static 
>> analysis can help resolve dependencies and record Package API 
>> signatures for fast runtime comparison before loading classes.
>>
>> So yes the goal is binary compatibility, currently in Jini, 
>> unmarshalled objects, if utilising downloaded code and not locally 
>> preferred classes, will be loaded in separate Classloaders, so they 
>> may not be visible to each other at runtime, yes they can participate 
>> if they share a common supertype or a common interface, however 
>> creating an interface for every domain object that should be shared 
>> is a lot of work.  Not only that, an interface, once created, doesn't 
>> evolve in a friendly manner, your domain objects become snared, not 
>> able to be refactored easily.
>>
>> So yes, the Jini discovery mechanism allows evolvability of systems 
>> by allowing new services to be made available, but they don't share 
>> objects nicely with the older existing services (unless you have 
>> locally installed preferred classes, which defeats the purpose of 
>> discovery) and they don't help with local Classloader isolation 
>> issues, nor will they assist with unmarshalling an object that has 
>> been persisted for which the URL from which the bytecode originated 
>> no longer exists.
>>
>> But I'm wondering, I think you know the River codebase far better 
>> than I do, you are far more qualified than I, so I think that you'd 
>> be surprised if I uncovered something you didn't already know, so I 
>> was hoping that you might rephrase that question again so I can 
>> better answer it?
>>
>> Regards,
>>
>> Peter.
>
>
>
>
>
>
>
>