Return-Path: 
 <ant-dev-return-15817-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 57090 invoked by uid 500); 18 Jul 2001 14:41:39 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 57081 invoked from network); 18 Jul 2001 14:41:38 -0000
Date: Wed, 18 Jul 2001 07:46:37 -0700 (PDT)
From: <cmanolache@yahoo.com>
X-X-Sender: <costin@costin>
To: <ant-dev@jakarta.apache.org>
Subject: Re: PATCH: taskdefs and class loaders
In-Reply-To: <00cc01c10f89$2d4a6130$a8020c3f@cognetnt>
Message-ID: <Pine.LNX.4.33.0107180735340.30700-100000@costin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: localhost.apache.org 1.6.2 0/1000/N

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