river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Change for PreferredClassLoader its way of determining the existence of PREFERRED.LIST ?
Date Wed, 24 Jan 2007 14:39:39 GMT
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

Mime
View raw message