Bug 8866 - Signal handling in java task
Summary: Signal handling in java task
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.4.1
Hardware: All other
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Depends on:
Reported: 2002-05-07 12:53 UTC by Simon Goldsmith
Modified: 2008-11-24 03:57 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Simon Goldsmith 2002-05-07 12:53:23 UTC
It would be nice to be able to catch Interrupt / Temrinate signals in the java 
task and forward them to the launched executable. This would *really* nice if 
it was a parameter on the task. 

For example (this is a hack tho') :

in the org.apache.tools.ant.taskdefs.Java class I changed the execute line to 
be :

execute = new Execute(new LogStreamHandler(this, 2, 1), new 

where the GracefulShutdownWatchdog is as follows:

public class GracefulShutdownWatchdog extends ExecuteWatchdog {
    public GracefulShutdownWatchdog(int timeout) {

    public void start(java.lang.Process process) {
      final Process p= process;
      Signal.handle(new Signal("INT"), new SignalHandler () {
          public void handle(Signal sig) {
            System.err.println("Child process INTERRUPT request recieved"); 
            try {
            catch(InterruptedException exc) {
              System.err.println("Interrupted whilst waiting for Running 
process to die gracefully");

    public void stop() {
      myWatching= false;
      myKilled= true;

    public void run() {

    public boolean isWatching() {
      return myWatching;
    public boolean killedProcess() {
      return myKilled;

    private boolean myWatching= false;
    private boolean myKilled= false;
    private Process myProcess;

This is only an example of what I was trying to achieve - not a recommendation 
fro the actual implementation. Part of the problem is that you cannot subclass 
the Java task to override the implementation of run(String[]) and you cannot 
get to the CommandLineJava memeber of the Java class to override the call in 
executeJava. A lot of the problem stems from the fact that it seems (to me 
anyway) virtually impossible to subclass org.apache.tools.ant.taskdefs.Java and 
get hold of the java.lang.Process created in the run(String[]) method. This 
makes it very difficult to pass on the signals to the forked JVM. My method 
above is to illustrate what I am trying to do, obviously there are better ways! 
(Apologies for abuse of the Watchdog :)