Hi Conor, > 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 ). 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. > Therefore, I would prefer an approach where the build file writer is > explicit about which tasks should use the same loader. Something like > > <taskgroup> > <classpath refid="blah"/> > <taskdef name="foo" classname="com.foo.Foo"/> > <taskdef name="bar" classname="com.foo.Bar"/> > </taskgroup> > > Thoughts? 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. Costin
