commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Lundberg (JIRA)" <j...@apache.org>
Subject [jira] Moved: (EXEC-24) [exec] Watchdog "shutdown"
Date Sat, 28 Jun 2008 05:41:46 GMT

     [ https://issues.apache.org/jira/browse/EXEC-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dennis Lundberg moved SANDBOX-193 to EXEC-24:
---------------------------------------------

    Fix Version/s:     (was: Nightly Builds)
      Component/s:     (was: Exec)
              Key: EXEC-24  (was: SANDBOX-193)
          Project: Commons Exec  (was: Commons Sandbox)

> [exec] Watchdog "shutdown"
> --------------------------
>
>                 Key: EXEC-24
>                 URL: https://issues.apache.org/jira/browse/EXEC-24
>             Project: Commons Exec
>          Issue Type: Improvement
>            Reporter: Reinhold F├╝reder
>            Assignee: Siegfried Goeschl
>
> 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.


Mime
View raw message