How do I get the full, server-side stacktrace to the client?

[icfantv]

I followed the instructions here:
http://cleancodematters.wordpress.com/2011/05/29/improved-exceptionhandling-with-gwts-requestfactory,
But they don't appear to be working.

I need to get the full, server-side stacktrace (if an exception is
thrown) to the client-side.

Anyone know how to do this? Thanks.

[Thomas Broyer]

Pass it as the message of the ServerFailure.

(honestly, you really *need* it? users don't need stack traces, developers need them, for debugging; if you're trying to extract some information from the stack trace, then you're doing it wrong: don't throw an exception, but rather return an "error object")

[icfantv]

Thanks. I'm doing this but I also do not see the stack trace in the
logs (you can see where I'm logging it below). This means I'm not
registering or configuring the handler correctly. I have a new
request factory servlet as thus:

public class FooRequestFactoryServlet extends RequestFactoryServlet {

public FooRequestFactoryServlet() {
super(new FooExceptionHandler());
}
}

Where the relevant code in FooExceptionHandler is:

@Override
public ServerFailure createServerFailure(Throwable throwable) {

LOGGER.error("A server error occurred", throwable);
return new ServerFailure(throwable.getMessage(), //
message
throwable.getClass().getName(), //
exception type
getFullStacktrace(throwable), // stack
trace
true); // is
fatal
}

FooExceptionHandler implements ExceptionHandler and
getFullStacktrace(...) simply returns a Stringified version of the
full stack trace.

Relevant lines from web.xml:
<servlet>
<servlet-name>gwtServlet</servlet-name>
<servlet-class>com.foo.FooRequestFactoryServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>gwtServlet</servlet-name>
<url-pattern>/gwtRequest</url-pattern>
</servlet-mapping>

Clearly, I'm missing something here...any ideas?

I do realize there's a debate of whether or not the end user *needs*
the stacktrace. If this were a production app and customer-facing,
clearly we wouldn't choose to do this. This is for internal systems
used by our divisions and anything they can give support when they
open a ticket will help the lower support tiers find and fix the
problem faster - rather than having to parse the logs from the
division in question. Sort of important when you have 52 divisions.

-ic