[
https://issues.apache.org/jira/browse/SANDBOX-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl resolved SANDBOX-193.
---------------------------------------
Resolution: Fixed
Added an ExecuteWatchdog.destroyProcess() including regression tests
> [exec] Watchdog "shutdown"
> --------------------------
>
> Key: SANDBOX-193
> URL: https://issues.apache.org/jira/browse/SANDBOX-193
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Exec
> Reporter: Reinhold Füreder
> Assignee: Siegfried Goeschl
> Fix For: Nightly Builds
>
>
> In my unit tests I use apache commons exec in combination with the execution
> watchdog for running some (Java) processes. By default, the processes should
> end normally. However, in case of an error the processes might still be
> running so I'd like to shut them down in the tearDown() cleanup step of the
> test case. In order to avoid modifying apache commons exec this is currently
> implemented like:
> @Override
> protected void tearDown() throws Exception {
> ...
> // This will implicitely lead to the required Process.destroy()
> call in case the process has not yet exited:
> watchdog.timeoutOccured(new Watchdog(1));
> watchdog.stop();
> ...
> }
> There are two issues:
> (1) At least in the current implementation there does not seem to be any
> reason anymore for the dummy watchdog argument in the timeoutOccured()
> method. Should we remove that? Of course this would also mean to remove it
> from the corresponding TimeoutObserver interface method. On the other hand,
> it removes some of the flexibility in case e.g. one extends the
> ExecuteWatchdog and requires more than one watchdog or so...
> (2) If this kind of watchdog "shutdown" (is there a better name?) is
> generally useful, shall we introduce an explicit method for it in the
> Watchdog class itself?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
