Эффективный доступ к HttpServletRequest для отладочных отпечатков

Question

Для отладки неудачных запросов я хотел бы распечатать всю информацию, поступающую из HttpServletRequest.

Теперь, возможно, что запрос будет частично потерпеть неудачу (например, несколько совпадений успешны, но одно не удалось), и в этом случае я хотел бы перехватить исключение во внутреннем методе, который не удалось, вывести ошибку + ServletUtil .toStringHttpServletRequest () и продолжить предоставление услуги (ухудшено, но все еще полезно против полной ошибки запроса).

Наша текущая реализация либо перехватывает исключение и печатает тупую информацию («getRules failed»), либо выдает исключение полностью вплоть до doGet () (фактически отменяя сервис для пользователя), где, как и в doGet (), у меня есть доступ к HttpServletRequest где я могу напечатать соответствующую информацию отладки (заголовки, параметры ...).

Передача HttpServletRequest каждой функции, вызываемой во время запроса, который может завершиться сбоем, кажется немного уродливой, я сделаю это, если не появится другое элегантное решение.

Создание предварительного заголовка ServletUtil.toStringHttpServletRequest () и сохранение его в карте ThreadLocal будет бесполезным как в памяти, так и во время процессора. По какой-то причине неправильно хранить объект HttpServletRequest в ThreadLocal (исправьте, если я ошибаюсь).

Отладочная информация записывается как в журнал локального компьютера, так и по электронной почте непосредственно разработчикам (отличная работа log4j TLSSMTPAppender ), поэтому регистрация в нескольких местах не будет практичной (потребуется разобрать несколько писем, чтобы понять что происходит) и ssh'ing на сервер старость :) (у нас все облачно ... сервера может не существовать, когда я увижу эту ошибку)

Итак, мое решение получает доступ к «PrintErrorUtility» (TODO: лучше назовите его). Он получит (String errorMsg, Throwable t, HttpServletRequest), который будет печатать ошибку вместе, получит всю необходимую информацию ... Это будет вызвано из внутренних блоков try {} catch, которые уведомят об ошибке, но не отменит запрос, потому что об этом.

Очевидно, я рассказываю о серверах, работающих в производстве.

Комментарии? Пожалуйста, сообщите.

Спасибо, Максим.

Answer 1

Выполните эту задачу в Filter после FilterChain#doFilter() вызова. Объект ServletRequest уже существует. В бизнес-коде, где это исключение должно изящно подавляться, сохраните исключение как атрибут запроса и просто позвольте Filter проверить / получить его из запроса.

---

Обновление : согласно комментариям, вот пример:

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);
    }
}

А вот как использовать его в сервлете вашего контроллера:

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

А вот как вы можете использовать его в исполняемом коде бизнеса:

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