ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject Re: PATCH: taskdefs and class loaders
Date Wed, 18 Jul 2001 15:07:14 GMT

> > It may be dangerous to assume that tasks which use the same classpath
> > use the same classloader. I am already dealing with a task which
> > initialises a singleton. If this task were to run in the same
> > the second use of the task would fail since it can't re-init the
> > It currently requires a different classloader per use. Now, while that
> > not be desirable, it is still possible.
> IMHO this is less intuitive ( having a task that uses a singleton or
> static variable, and each invocation creates _another_ singleton ).

This is the situation, today, with the Anakia task. I agree it is probably
less intuitive, but it is a definite reality. It may even be common where a
task adapts an external application for use in Ant.

> The patch is using the same loader for taskdefs using the same refid -
> so you can still have both behaviors ( just define a new classpath, with
> different refid ). I think it's intuitive enough - each classpath
> definition ( be it at top level or not ) result in a single class loader.

OK, perhaps. I guess I just feel more comfortable with that relationship
reflected in the build file structure rather than the implicit linking
through the use of the same classpath.

> That's the second half of the patch :-) ( taskdef with file= or
> and all definitions loaded from a properties file with the same loader).
> Same syntax/behavior as in Properties.

So, is that an OK way to go for you? I'd rather have the capability in the
build file than need to have an external properties file (which can still
be used, of course).

BTW, can you give us the motivation for why these tasks need to be in the
same classloader.


View raw message