Return-Path: 
 <river-dev-return-216-apmail-incubator-river-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-river-dev-archive@locus.apache.org
Received: (qmail 52305 invoked from network); 24 Jan 2007 14:59:42 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 24 Jan 2007 14:59:42 -0000
Received: (qmail 25007 invoked by uid 500); 24 Jan 2007 14:59:49 -0000
Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org
Received: (qmail 24940 invoked by uid 500); 24 Jan 2007 14:59:48 -0000
Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:river-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:river-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:river-dev@incubator.apache.org>
List-Id: <river-dev.incubator.apache.org>
Reply-To: river-dev@incubator.apache.org
Delivered-To: mailing list river-dev@incubator.apache.org
Delivered-To: moderator for river-dev@incubator.apache.org
Received: (qmail 85325 invoked by uid 99); 24 Jan 2007 14:42:04 -0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of
 SRS0=Wc48WR=HB=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.85 as permitted sender)
Message-ID: <45B76FAB.1010108@wonderly.org>
Date: Wed, 24 Jan 2007 08:39:39 -0600
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Change for PreferredClassLoader its way of determining
 the	existence
 of PREFERRED.LIST ?
References: <45A3F189.8040809@cheiron.org> <45A67ED8.80907@Sun.COM>
 <45A6B402.20406@cheiron.org> <20070116212605.GP20922@east>
 <45ADE8D2.5030904@cheiron.org> <20070122184822.GC25418@east>
 <45B5EE76.4000500@cheiron.org> <45B62537.4040806@wonderly.org>
 <45B70E78.3070705@cheiron.org>
In-Reply-To: <45B70E78.3070705@cheiron.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-EN-UserInfo: 
 5bac21c6012e8295aaee92c67842fba3:ac7a8090b38574d26045e9ce00487feb
X-EN-AuthUser: greggwon
Sender: Gregg Wonderly <gregg@wonderly.org>
X-Virus-Checked: Checked by ClamAV on apache.org

Mark Brouwer wrote:
> Gregg Wonderly wrote:
>> I think that the behavior of fallback URLs is useful.  Given the 
>> framework that
>> exists, I think that the current implementation is applicable.  But, I 
>> also
>
> I've a bit of a problem positioning your language Gregg due to the words
> fallback and framework, but are you suggesting the new behavior should
> be conditionally. Note that as far as I can tell the only
> de-optimization is the one Peter will be remembered for the rest of his
> life.

Let me try with different words...

If there are multiple URLs in the codebase, and two or more actually points at 
the same content, then one of those URLs can be considered "fallback" URLs. 
I.e. if one URL is not accessible, the client will hopefully be able to load 
code from another.  Thus, the failure handling associated with "JAR not 
accessible" as opposed to "PREFERRED.LIST" not present is important.  Also, the 
location that the PREFERRED.LIST comes from is important.

You are familiar with XML based configuration.  Imagine that you could send an 
XML document at the codebase which said something like:

<codebase>
     <entry>
	<source path="/reggie-dl.jar" host="srv1" port="8090"
		protocol="vhttp,http"
		preferredSource="true"/>
	<source prefurl="vhttp://srv2:8090/reggie-dl.jar"
		alturl="http://srv2:8090/reggie-dl.jar"
		preferredSource="true"/>
     </entry>
     <entry>
         <!-- Never prefer these classes, but make them available for
              loading if needed -->
	<source prefurl="http://srv1:8090/jsk-dl.jar"
		/>
	<source prefurl="http://srv2:8090/jsk-dl.jar"
		/>
     </entry>
</codebase>

The above is an example of different formats to just show structure and 
potential options, not to indicate what should happen in practice.  By creating 
a structured specification, we could ammend the codebase annotation over time so
that specific application needs might be customized with interoperability still 
allowed.  The issues that I'm thinking about are:

o  Where should a preferred list be found?
o  Can we specify multiple urls with different protocols to provide for
    different qualities of service?
o  What order are the codebase entries searched?
o  How do you specify backup/fallback codebase entries?

There's other types of things that I've mulled over too.  This is basically what 
I was thinking about in my original comment.

As soon as the codebase has some kind of structure like this, then an 
appropriate RMIClassLoaderSPI will have to be present on the receiving end in 
particular, to deal with this.  Because of my use of vhttp: in codebase URLs, I 
understand the issue of having special setup required on all ends to make use of 
such customizations.

Gregg Wonderly