> From: Russell Johannesson [mailto:[EMAIL PROTECTED] > > > From: Russell Johannesson [mailto:[EMAIL PROTECTED] > > > > > > It occurs to me that the problem under discussion isn't necessarily > > > specific > > > to ClearCase. Wouldn't any task which employs Runtime.exec() > >internally > > > potentially be a source of unwanted output? Would it be reasonable to > > > request that there be control over the exec output of all such tasks? > >That > > > way, having ClearCase wouldn't be necessary for testing. > > > >Sounds like a good idea. If you could nest <filterreader>s inside > ><exec>, you'd have some control over the output. Don't know how that > >would mesh with <redirector> through. --DD > > Perhaps it could be done with filters. The <exec> task's output can be > redirected with the output attribute. I was referring to any and all other > tasks that may use Runtime.exec internally.
Ah, I get it. What would work then would be a <redirector>-like task you could wrap around any block of tasks, a bit like <sequential>, but which would accept a <filterchain> (like <redirector>). Or go the <record> route so it works across targets. I'm not sure whether it's possible though, since you'd have to intercept log messages before they are broadcast to all listeners, including the default logger. AFAIK, <redirector> works directly at the source of the output, in Execute, before it reaches the log sub-system. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
