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)
