On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> I wrote an Antlib with:
>
> public void addConfigured(AntlibInterface nestedTask) {
> System.out.println("Antlib: addConfigured");
> if (nestedTask instanceof Task) {
> setLocation(((Task) nestedTask).getLocation());
> }
> nestedTask.setURI(uri);
> nestedTask.setAntlibClassLoader(getClassLoader());
> if (nestedTask instanceof Task) {
> ((Task) nestedTask).perform();
> }
> }
>
> and tested it with an antlib:
>
> <antlib xmlns:c="ant:current">
> <presetdef name="define.with.echo">
> <typedef classtype="org.apache.tools.ant.taskdefs.Echo"/>
> </presetdef>
> <c:define.with.echo name="define.test"/>
> </antlib>
>
> The <c:define.with.echo> element gets rejected in
> UnknownElement#handleChildren() before
> Antlib#addConfigured() is called for the <presetdef> element
> of the antlib.
I see. It seems we have a certain class of tasks with "what can be
nested into the task depends on what has been nested into it before".
<sequential> was the first with that problem and we fixed it by
special casing TaskContainer.
The way TaskContainer is treated here has always been a hack - well,
most of the UnknownElement/RuntimeConfigurable combo is ;-) - and it
sure felt better if we'd have a clean way to signal that an object
needs to defer child creation. I now understand why you went the
Taskcontaier route and would be OK with rejecting non AntlibInterface
instances for now.
The alternative might by DynamicConfigurator which itself could defer
the child creation.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
