river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: Change for PreferredClassLoader its way of determining the existence of PREFERRED.LIST ?
Date Wed, 24 Jan 2007 15:28:12 GMT
Gregg Wonderly wrote:
> 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...

Ok I understand where you want to go to, however there was a thread
during the Davis project which I'm unfortunately can't refer to as the
archives have been closed, where I also referred to the current
semantics for having the requirement of PREFERRED.LIST in the first JAR
file. I attached my post and the responses of Peter and Laird Dornin for
completeness.

There is an issue in the Sun bug database
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4302427 that suggest
that the fallback behavior you are referring to in itself is a bug.

Based on the current semantics of PreferredClassLoader the proposed
change doesn't alter its behavior.

> 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 

Is that a complement Gregg ;-) I think we should start a separate thread
on improvements of codebase annotation for it seems you just want to
have a complete new protocol handler Gregg that solves many issues
around mobile code, but I think I leave it up to others who have done
their fair share of research/thinking to comment on this first.
-- 
Mark


Mime
View raw message