Question

In order to debug failing requests I would like to print all information coming from HttpServletRequest.

Now, it’s possible that a request will partially fail (for ex. Several matches are successful, yet one has failed) in which case I would like to catch the exception in the internal method that failed, print the error + the ServletUtil.toStringHttpServletRequest() and continue providing service (degraded but still useful vs. complete request failure).

Our current implementation either catches the exception and prints dumb info (“getRules failed”) or throws the exception all the way to doGet() (effectively canceling service for the user) where as in doGet() I have access to HttpServletRequest where I can print at the relevant debug info (headers, parameters…).

Passing HttpServletRequest to every function called during the request that might fail seems a bit ugly, I will do it if no other elegant solution will pop up.

Making a before head ServletUtil.toStringHttpServletRequest() and storing it in a ThreadLocal map would be wasteful both in memory and CPU time. For some reason it feels wrong to store the HttpServletRequest object in ThreadLocal (please correct if I’m wrong).

Debug information is written both to local machine log and is emailed directly to devs (Great work log4j TLSSMTPAppender), so logging in several places won’t be practical (Will need to assemble several emails to understand what’s going on) and ssh’ing into the server is old age 🙂 (We’re all cloudy here… server might not exist by the time I get to look at the error)

So, my solution is gaining access to a “PrintErrorUtility” (TODO: better name it). That will receive (String errorMsg, Throwable t, HttpServletRequest) which will print the error together will all the relevant info… This will be called from internal try {} catch blocks that will notify about the error but will not cancel the request because of it.

Obviously I’m taking about servers running in production.

Comments? Please advise.

Thank you, Maxim.

Answer 1

Do this task in a Filter after the FilterChain#doFilter() call. The ServletRequest object is already there. In the business code where this exception is to be suppressed gracefully, store the exception as a request attribute and just let the Filter check/grab it from the request.

---

Update: as per the comments, here’s an example:

public class Context { 
    private static ThreadLocal<Context> instance = new ThreadLocal<Context>();
    private HttpServletRequest request;
    private List<Exception> exceptions = new ArrayList<Exception>();

    private Context(HttpServletRequest request) {
        this.request = request;
        this.request.setAttribute("exceptions", exceptions);
    }

    public static Context getCurrentInstance() {
        return instance.get();
    }

    public static Context newInstance(HttpServletRequest request) {
        Context context = new Context(request);
        instance.set(context);
        return context;
    }

    public void release() {
        instance.remove();
    }

    public void addException(Exception exception) {
        exceptions.add(exception);
    }
}

And here’s how to use it in your controller servlet:

Context context = Context.newInstance(request);
try {
    executeBusinessCode();
} finally {
    context.release();
}

And here’s how you could use it in the executed business code:

} catch (Exception e) {
    Context.getCurrentInstance().addException(e);
}