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
