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
