On Fri, 25 Feb 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>
>>On Thu, 24 Feb 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>> * <classloader> to allow adding of jars to the current
>>> classloader (would solve a *lot* of problems at the cost of
>>> some issues)
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=28228
>>>
>>>
>>
>>I'm willing to not cast a -1 on it, if it is documented that the
>>task is dangerous and should be handled with out,ost care.
>
> This is for sure.
>
> It is *very* dangerous. For example when used within netbeans, the
> ant-classpath is changed in one build, and this is carried over the
> the next build.
Yes. This is one example.
Another one is a scenario where you try to load a class from a
classloader and fail (and may thus load it from a different loader)
and add that class to the first classloader later. This leads to
classes that have been loaded twice in a class loader hierarchy and
all kinds of impossible to debug ClassCastExceptions.
>>Oh, and it must adhere to the build.sysclasspath setting 8-)
>>
> This is something to look into.
>
> Like most of the ant code, it does check for the setting "only", but
> not for the other settings ("ignore", "last" and "first").
I'm content with having it honor the "only" setting.
"ignore" doesn't mean anything special in <classloader>'s context.
"last" is difficult to implement since some parts of the system
classpath may have been part of the classloader already, so it's
dofficult to find the insert-point for the new URL. "first" should
work out of the box since the new URLs are appended IIRC.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
