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 16:58:11 GMT
Mark Brouwer wrote:
> Gregg Wonderly wrote:
>> 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.

The failover behavior, is something that I desire to be possible.  The current 
"glib" as Laird put it behavior of URLClassLoader, is probably not the right way 
to do it, considering the case where you've purposely put a codebase component 
in front of another to avoid using classes in the following component.  In other 
cases, where you might compose

	http://host1:8090/jarv2-dl.jar http://host1:8090/jarv1-dl.jar

to say you prefer the use of v2, but if it's not present than v1 is okay, and 
then in a deployment, delete v2 because the customer hasn't paid for the upgrade 
  yet, that, is a different issue.

I'm all for improvements.  I just don't think that the simple string annotation 
structure that we have now, is capable of documenting the deployers true intent.

Making alterations to limit exploitations as I've enumerated above, would be 
acceptable to me because I don't do any of these things, because I don't find 
the behavior dependable.

It's that dependable behavior that I think would be something to create, if 
anything really needs to be done with annotations.

Gregg Wonderly

Mime
View raw message