Комментарии 6
Я уж подумал, что то оригинальное (автоматом имя вызова контекста).
Потом увидел:
Чтобы логбэк мог отличить один метод от другого, перед вызовом метода сохраняем его имя в ThreadLocal Mapped Diagnostic Context.
А при таком подходе это, по моему, любой логе делает.
Вот например, для log4j2
import org.apache.logging.log4j.ThreadContext;
..
ThreadContext.put("LOG_SUFFIX", "blabalProcName");
<RollingFile name="Rolling-${ctx:LOG_SUFFIX}" fileName="${log-path}/xxxxx${ctx:LOG_SUFFIX}"
filePattern="${log-path}/xxxx${ctx:LOG_SUFFIX}-%d{yyyy-MM-dd}.gz">
<PatternLayout pattern="%d{dd MMM HH:mm:ss.SSS}:%c:tid [%t]:%p: %m %X{SID}%n" charset="UTF-8"/>
...
Хотя задача, по моему, высосана из пальца.
Допустим, нам захотелось логировать каждый метод некого Java-класса по разному:
Логирование нити или группы нитей или подобное — понятно. А отдельных вызовов…
Даже не знаю зачем это может понадобится.
Мы как-то однажды в древнем проекте делали
import org.jboss.logging.MDC;
// ...
MDC.put("job", " [Job: " + job.getId() + ']');
// ... всякий рефлексивный вызов фактического тела задачи
MDC.remove("job");
Там, кажется, ThreadLocal-подобная переменная, которая наследуется по дочерним потокам.
Но это была задача логирования целой группы потоков, как mmMike сверху сказал.
Наверное, это похоже на логирование одного метода, особенно если он крупный.
Спасибо, что собрали материал в одном месте. :)
Если есть аспекты в проекте, то это решается аннотацией методов, которые хочется логгировать и аспектом, который это делает. Тогда совершенно пофиг какой у вас логер. Туда же можно запихнуть алертинг, трассировку… и черта лымого, который проходит через весь проект… что суть аспектов
Раздельное логгирование методов в Java/logback