Исключение нулевого указателя генерируется, когда приложение пытается использовать null в случае, когда требуется объект. К ним относятся:
null
. null
. null
, как если бы это был массив. null
, как если бы это был массив. null
как будто это было значение Throwable. Приложения должны бросать экземпляры этого класса, чтобы указать на другие незаконные использования объекта null
.
Ссылка: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html
Необходимо также взглянуть на вложенную диагностическую функцию контекста log4j. Продвижение различных контекстов к регистратору для различных вызывающих сторон могло бы добиться цели для Вас.
В log4j можно зарегистрировать имя потока с "%t" шаблоном. См. log4j Расположение Шаблона.
Необходимо смочь раздать регистратор, таким образом, Вы создаете регистратор на основе некоторых "характерных" для данных задачи - т.е. имя пользователя и т.д. Затем передайте этот регистратор как параметр ко всем методам, в которых Вы нуждаетесь. Тем путем Вы сможете установить различные фильтры и/или правила в Вашем log4j файле конфигурации. Или очищать выходной файл на основе названия регистратора.
Править: Также проверьте MDC и классы NDC в log4j. Можно добавить там данные контекста.
Вы хотите связать объекты регистратора с потоками, я думаю. Переменная ThreadLocal содержание log4j экземпляра регистратора для каждого потока могла бы помочь:
http://java.sun.com/javase/6/docs/api/java/lang/ThreadLocal.html
В Java5 (и позже) можно звонить
StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
Осмотрите отслеживание стека на любую глубину, которую Вы хотите и регистрируете соответственно.
В Java 1.4 можно получить ту же информацию с
StackTraceElement[] stackTrace = new Exception().getStackTrace();
В одном из моих (веб-) приложений я использую регистратор ThreadLocal, который получает регистрирующуюся информацию в StringBuilder. Объект регистратора инициализируется в методе HttpServlet#service, если параметр трассировки устанавливается (если он не установлен, существует очень быстрый пустой регистратор). Получающийся вывод или выведен как комментарий HTML в страницу запроса или записан в файл журнала в одном сегменте.
Необходимо будет передать некоторую структуру уровню доступа к данным, который определяет текущее "действие". У Вас могло бы уже быть "Действие" - класс, который имеет смысл, Вы могли бы использовать экземпляр Регистратора в качестве Солнечного предложенный, или Вы могли бы использовать третью структуру для отслеживания контекст действия.
В любом случае, так как Ваше "действие" обрабатывается через несколько потоков, которые Вы не можете использовать локальную память потока для того, чтобы отслеживать текущее "действие", как большинство других текущих ответов предлагают. Необходимо будет раздать его явно.
Я предложил бы делать небольшой фасад сверху log4j, который разворачивает интерфейс с методами как
void debug(Activity activity, String message);
и передача контекста действия в это от уровня доступа к данным.
Необходимо будет сделать некоторую модификацию к уровню доступа к данным, чтобы позволить Вам передавать текущее действие ему, но как лучше всего сделать, который зависит сильно от текущего интерфейса. При использовании Шаблона рабочей области Вы, возможно, просто должны были бы добавить setActivity () метод на Классе рабочей области, но другой интерфейсный шаблон мог бы потребовать, чтобы Вы добавили параметр Действия ко всем методам.
Если Вы по некоторым причинам неспособны или не желаете изменить уровень доступа к данным, Вы могли бы, конечно, сохранить контекст действия в локальной памяти потока прежде, чем вызвать уровень доступа к данным и получить его прежде, чем породить подпотоки или enqueing задания на уровне доступа к данным. Это - осуществимое решение, но является им немного опасный для раздавания информации таким образом.