Question: In the client program on which I work, we dispatch server calls to different Threads, to not lock the UI (equivalent of a SwingWorker).

This is made with a model class inheriting an abstract class containing the "update" method, which is preparing the new thread, and executing the code from an abstract method in this newly created Thread (plus other tweaks)

It works correctly, but my issue is that when debugging (or logging), it is hard to keep track of which method exactly called the "update" method, since the stack trace ends with the creation of the new Thread.

**What would be the proper way to keep track of the stack trace which led to call this new Thread?** Ideally, in a way which would show in the debugger's stack navigator (from Eclipse in this case; the idea is to navigate easily in the initial context).

Answer: 
You say you do "like SwingWorker". In this case, why not using an [ExecutorService](http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html) ? Java concurrent framework is pretty well made, and would allow you to avoid the classic pitfalls of threading, amongst them your question.
I just had the same problem - multiple points in the system were sending a mail through the same logic wrapped in an `ExecutorService`.

Just like @daveb I create an empty `Exception` and pass it into the `Runnable`:

```
Executors.newSingleThreadExecutor().submit(new Mailer(..., new Exception()));

```

Now inside of `Mailer` I have the `Exception` instance to use in logging expressions:

```
public Mailer(..., final Exception originalStackKeeper) {
  ...
  this.originalStackKeeper = originalStackKeeper;
}

...
LOG.error("There was an error while sending mail, originating here: ", 
    originalStackKeeper);

```

But even better: whenever I catch an exception in `Mailer`, I can do this:

```
} catch (final SomeException e) {
  LOG.error("There was an error while sending mail.", 
      originalStackKeeper.initCause(e));
}

```

So I tell the original `Exception`: let's use your stack: here is the cause why we are using you, and here we are logging you. It seems to me that this is not really a hack, but rather a clean way to use the "cause" mechanism in Java exceptions.