I know that pretty well ( reverse loader is required by 2.3+ servlet spec -
one of the biggest mistakes IMHO ).
Yes, that is pretty weird.
There are some cases where a reverse loader will help, and is actually needed.
I think it mainly helps when the classloader hierarchy is not clean and you need to workaround that (true in Ant to some extent).
In Ant a long time ago, I let the classloaders all be reversed and it was not a good thing. I corrected that with a potentially backward compatability breaking change to make most Ant uses of classloaders respect the loader hierarchy.
As a slight concession I introduced, but did not document, the reverseLoader attribute. It was intended to allow the old behaviour to be accessed if it turned out to be required. For the most part it has not. Only Velocity/Anakia had problems due to the use of singletons that needs to be isolated.
There are two locations in Ant where the classloaders do not strictly respect the hierarchy - the <java> task and the <junit> task. In both cases this is an attempt to make running a class behave the same as it would if it were to be run within its own VM. You'll also note that this is where people encounter LinkageErrors a lot (see Ant user list). Fortunately both these tasks allow the operation to be forked into a separate VM bypassing the classloader issues altogether.
The new task, however, makes it easy to expose this problem. In this case the problem would manifest itself in not just the <java> and <junit> tasks but anywhere within Ant's core. It would not be easy to solve these problems by saying "set fork=yes" as we do now.
It would also not be easy to diagnose these problems since the manifestation of Linkage Errors is far from the source of the problem and can depend on many factors including garbage collection. For example I have seen behaviours such
* working on the first run (one classloader),
* failing on the second (two classloaders with overlapping paths),
* working on second run if delayed (garbage collection cleaning up)
That sort of problem drives people nuts.
I'd rather people bump into the problems of the loader hierarchy limitations (normally ClassNotFound) since these errors represent a "fail-fast" situation and the workarounds can be driven from there (rejig classpaths, etc)
Is your -1 on "global non-delegate behavior", or also on support for parentFirst for individual packages ?
My -1 applies to any user ability to avoid the classloader heirarchy.
Thoughts?
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
