ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey E Care <>
Subject Re: AW: Guidelines for executing delegate tasks?
Date Wed, 02 Nov 2005 13:33:39 GMT
Right, I understand the code path, and in this case that code path is 
what's causing the problem. 

Definer is programmatically creating & using a "delegate" instance of the 
antlib task to bind the antlib namespace; to make the delegate do its work 
Definer is using the perform method, which as you mention fires the 
taskStarted/taskFinished events. A side effect of the taskStarted event is 
that the thread/task registration in oata.Project gets reset to be 
whatever task caused the event to be fired. In the normal course of 
running targets that is what you want, but when using a delegate task you 
lose contextual information this way when the delegate fires its 
taskFinished event. When taskFinished is fired the thread/task 
registration is cleared, so in this case when the delegate finishes there 
is no task registered for the current thread, despite the fact that there 
is a task still running. (I hope I'm explaining it clearly - it's a fairly 
complex scenario.)

My patch was to simply make Definer call "execute" rather than "perform" 
on the delegate antlib instance. Another, possibly more robust, solution 
would be to make the thread/task registration be a stack per thread, 
rather than the single entry per thread that it is now. I can work on a 
patch for that solution if folks think that would be a better way to 
handle this problem.

Jeffrey E. Care (
WebSphere v7 Release Engineer
WebSphere Build Tooling Lead (Project Mantis)

<> wrote on 11/02/2005 04:35:08 AM:

> Hello Jeffrey,
> as far as I can see
> - the perform() method is called by Ant and
> - the execute() is implemented by the taskwriter.
> Usually you are overwriting the Task.execute() method - which has an 
> empty implementation in Task [1]. The Task.perform() does event firing
> (task starts/ends) framework internal configuration and calls the 
> method. So overwriting this method seems to be the "right" way.
> Coming from my idea that a project holds several targets the project
> should call
> a method from the target to perform all the tasks work. So I did a look 
> Target [2]. There are two methods: performTasks() and execute(). The
> perform does
> only event firing (target starts/stops) and calls the execute() 
> method. That method
> iterates over all tasks and calls that perform() method!
> So the stack is
>   target.performTasks()
>   target.execute()
>   task.perform()
>   task.execute()
> Now lets have a look at the Definer task [3] ... öh ... is this the 
> task you mean?
> What would your patch be? Maybe you could send it to the list.
> Jan
> [1] http://svn.apache.
> org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/
> [2] http://svn.apache.
> org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/
> [3] http://svn.apache.
> java
> >-----Urspr√ľngliche Nachricht-----
> >Von: Jeffrey E Care [] 
> >Gesendet: Dienstag, 1. November 2005 23:50
> >An:
> >Betreff: Guidelines for executing delegate tasks?
> >
> >All:
> >
> >I've recently encountered some difficulties with the 
> >multithreaded build extensions that I've mentioned on the list before. 
> >
> >As part of the Mantis project that we use to build WAS we have 
> >a custom logger. This logger uses a different banner format 
> >([project/target/task]) from the default logger. The current 
> >problem is that the banners on messages from the sub-builds 
> >have the wrong context information; specifically they either 
> >no context (i.e. the banner is empty) or they have the parent 
> >project's context.
> >
> >I've done a lot of debugging in the past few days and found 
> >that the parent context bit is due to a bug in our code, so 
> >mea culpa there. But the no context bit I traced to some code 
> >in oata.taskdefs.Definer. Definer creates an Antlib task 
> >instance to load our antlib. Now, creating a "delegate task" 
> >is a fairly common pattern; I do it in Mantis a lot. The 
> >problem (as I see it anyway) is that Definer calls "perform" 
> >instead of "execute" to make the Antlib instance do its work. 
> >Because "perform" is used that blows away the currently 
> >registered task for the current thread. 
> >I've overridden Definer locally to call "execute" instead of 
> >"perform" and my problems seem to have cleared up with no 
> >side-effects. (Also interesting that this isn't really 
> >threading related - it happens even when everything is running 
> >on the main thread.)
> >
> >So, getting to the point, is there a general policy regarding 
> >"execute"/"perform" for delegate task instances? Based on my 
> >experience I would think that "execute" would be preferred, so 
> >I wasn't sure if "perform" was required in this instance. I've 
> >prepared a patch for Definer, but I didn't want to open a 
> >bugzilla report until we had some discussion here on the list.
> >
> >Cheers,
> >JEC
> >--
> >Jeffrey E. Care (
> >WebSphere v7 Release Engineer
> >WebSphere Build Tooling Lead (Project Mantis)
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message