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. JEC -- Jeffrey E. Care ([EMAIL PROTECTED]) WebSphere v7 Release Engineer WebSphere Build Tooling Lead (Project Mantis) <[EMAIL PROTECTED]> 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 execute() > 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 at > 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/Task.java > [2] http://svn.apache. > org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/Target.java > [3] http://svn.apache. > org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Definer. > java > > > >-----Ursprüngliche Nachricht----- > >Von: Jeffrey E Care [mailto:[EMAIL PROTECTED] > >Gesendet: Dienstag, 1. November 2005 23:50 > >An: dev@ant.apache.org > >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 ([EMAIL PROTECTED]) > >WebSphere v7 Release Engineer > >WebSphere Build Tooling Lead (Project Mantis) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
