Costin, > > > It may be dangerous to assume that tasks which use the same classpath can > > use the same classloader. I am already dealing with a task which > > initialises a singleton. If this task were to run in the same classloader, > > the second use of the task would fail since it can't re-init the singleton. > > It currently requires a different classloader per use. Now, while that may > > 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 resource=, > 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. Thanks Conor
