Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4E5BFF36.4020006@cox.net>
Date: Mon, 29 Aug 2011 16:05:58 -0500
From: Gregg Wonderly <gergg@cox.net>
User-Agent: Mozilla/5.0 (Windows NT 6.0;
 rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: dev@river.apache.org
CC: Peter Firmstone <peter.firmstone@zeus.net.au>
Subject: Re: Usability - "The Platform"
References: <4E59F9DD.7060200@zeus.net.au> <4E5B4C7D.5080806@zeus.net.au>
 <4E5B6AA8.1060707@zeus.net.au>
In-Reply-To: <4E5B6AA8.1060707@zeus.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter, I am not sure I really understand the exact issue(s) that you want to 
resolve.  Jini has the behavior that clients dynamically discover the "code" 
that they will use.  OSGi has the attribute that clients load packages for the 
"code" that they use.  In both cases, the deployment mechanism has established 
the content that is "the code".  OSGi includes more literal dependency 
specifications from each packages perspective.  Jini doesn't do it that way. 
Instead, the "codebase" and "classpath" mechanisms are used to "tell" the system 
that is built what to do.

When you get into a more arbitrary environment like "the internet", then more 
expressive and more detailed relationship descriptions between packages can help 
make it possible for multiple packages to use multiple versions of the same 
package.  The code in com.sun.jini.start provides the mechanism for services to 
be separated from each other, but not from the system classpath.

I think it would be a good idea to just detail the concerns first, and then 
discuss where those concerns are visible or problematic so that we can work 
through any other issues that might be stimulated forth, out of the discussion.

Gregg

On 8/29/2011 5:32 AM, Peter Firmstone wrote:
> On 29/08/2011 6:23 PM, Peter Firmstone wrote:
>>> On 28 August 2011 09:18, Peter Firmstone<peter.firmstone@zeus.net.au> wrote:
>>> >
>>> > Then we stop using the preferred classes mechanism by default.
>>> >
>>>
>>> Why?
>>>
>>> > This will allow us to prevent codebase annotation loss.
>>> >
>>>
>>> Because of annotation loss? That's quite a serious compromise and
>>> prevents service implementers from doing version management of code in
>>> their proxies amongst other things. That's a killer as it requires all
>>> services to move with the platform all the time which implies forced
>>> mass upgrades etc.
>>
>> Hmm, ok, so these are implementation private copies / concerns, unless they
>> share a common interface or superclass with the platform.
>>
>> The other alternative exteme is to prefer all classes other than those in the
>> service api, meaning the proxy get's to have all it's own implementation
>> classes, this would definitely prevent codebase annotation loss.
>>
>> So if that's the case, is it possible to automate the preferred list?
>>
>> Now what happens if we extend an existing Service API and the extension
>> classes are not installed on the client, the proxy must download them.
>>
>> So how about for all codebase annotations ending in *api.jar, we consult the
>> parent classloader first, followed by the proxy ClassLoader
>> (PreferredClassLoader) and for all other codebases, we try the proxy
>> Classloader first, then the parent classloader if not found, or perhaps only
>> the proxy classloader then throw a ClassNotFoundException?
>
> This would require some very carefull thought, feel free to mention any gotcha's
> you can think of. Any java classes would also have to delegate up.
>
> Perhaps this isn't quite the right approach, perhaps the right approach is to
> create a tool that generates preferred class lists for developers, all comments
> and thoughts are welcome.
>
> Another problem is, if a client retains references to objects from a proxy, this
> can prevent the proxy classloader from being garbage collected, even if the
> client has finished with the proxy itself.
>
> To me it appears that the client and proxy should only interract using the
> service api or common interfaces and jvm classes. This would also be useful to
> enable clients and proxy's to run is separate jvm's, where each has it's own
> runtime zone? In this case the proxy could use one version of a class, while the
> client uses another, provided that the serialized form is still compatible, you
> don't have to suffer the ClassLoader visibility problems then.
>
> Cheers,
>
> Peter.
>
>>
>> Then developers don't need to try figure out what classes are preferred,
>> simplifying development.
>>
>> This allows each proxy to have it's own private implementation namespace.
>>
>> Thoughts?
>>
>> Cheers,
>>
>> Peter.
>>
>>
>
>