Sorry, just see now that you opened a bug [1]. I´ll have a look at that. Jan
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37328 >-----Ursprüngliche Nachricht----- >Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Gesendet: Mittwoch, 2. November 2005 10:35 >An: dev@ant.apache.org >Betreff: AW: Guidelines for executing delegate tasks? > >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/apa >che/tools/ant/Task.java >[2] >http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apa >che/tools/ant/Target.java >[3] >http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apa >che/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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
