Мысль сделать то же самое с помощью AspectJ, конечно, была. И в общем-то продолжает витать.
Первоочередной челленжд всё же был в том, чтобы реализовать необходимый функционал и сформировать удобный для использования подход. Вышло ли достаточно удобно — наблюдаем.
Как естественное развитие в сторону снятия ограничений и дальнейшего упрощения работы — будем рассматривать. Тем более, если сообщество проявит интерес к такому преобразованию.
Спасибо за наводку, интересно пронаблюдать другую точку зрения на решение тех же задач.
Для себя отметил, что больше уделено внимания настройке визуального формата (скобки, разделители, отступы и подобное). Но, кажется, даёт меньше гибкости и требует больше внимания со стороны разработчика хотя бы в задаче маскирования. На сколько я понял по описанию, требуется глазами отследить, где логируются данные, которые нужно скрывать. И проконтролировать их скрытие самостоятельно.
Мне показался такой путь трудным и ненадёжным. Поэтому в Eclair можно помимо ручного выбора формата для распечатки привязать ru.tinkoff.eclair.printer.Printer к типу аргумента (на весь контекст) и этот принтер будет выполнять свою работу в любом месте приложения, уже без ручного контроля.
Пользоваться aspect4log, оговорюсь, не приходилось. И во время разработки Eclair я о таком инструменте не знал, поэтому могу оценивать слишком поверхностно.
В совместном использовании нет никаких проблем. ru.tinkoff.eclair.logger.ManualLogger — это не отдельный бин, а interface, который реализован включенным в автоконфигурацию EclairLogger'ом.
В примере приведено внедрение через interface. Default'ный логгер его реализует, но делать это не обязательно.
Если сравнивать с @Slf4j, на ум приходят такие отличия:
1) Eclair включает имя логируемого метода в имя логгера (не только при ручном логировании, а вообще всегда), например: ru.tinkoff.eclair.example.Example.simple
Благодаря этому есть возможность настраивать через конфигурацию уровни доступного лога не только для пакета/класса, но и для отдельных методов.
Это бывает полезно, когда точно знаешь, в каком месте нужно повысить подробность лога до DEBUG или TRACE, но включать DEBUG для всего класса нет желания (из-за больших объёмов лога или проседания скорости).
2) ManualLogger имеет набор «сахарных» методов, например ManualLogger#warnIfDebugEnabled("some").
Такой метод может быть полезен, если в логике обрабатывается некоторое предупреждение (warning), которое не слишком важно, но если для текущей локации доступен DEBUG, то его нужно залогировать как WARN.
Того же можно добиться с помощью @Slf4j, но менее лаконично: if (log.isDebugEnabled()) { log.warn("some"); }
3) ManualLogger принимает в качестве аргументов Supplier'ы. На сколько я понимаю, в зависимости о того, что лежит «под» @Slf4j-логгером, ты не всегда имеешь возможность провернуть «ленивую» инициализацию аргументов.
4) В метод ManualLogger#log есть возможность передать LogLevel, определяемый динамически. Это тоже для особых ценителей. Не сказать, что сильно важная способность.
Если эти способности не востребованы, и достаточно стандартного интерфейса slf4j, а также сам Lombok не является проблемой, вполне можно ограничиться @Slf4j.
Первоочередной челленжд всё же был в том, чтобы реализовать необходимый функционал и сформировать удобный для использования подход. Вышло ли достаточно удобно — наблюдаем.
Как естественное развитие в сторону снятия ограничений и дальнейшего упрощения работы — будем рассматривать. Тем более, если сообщество проявит интерес к такому преобразованию.
Для себя отметил, что больше уделено внимания настройке визуального формата (скобки, разделители, отступы и подобное). Но, кажется, даёт меньше гибкости и требует больше внимания со стороны разработчика хотя бы в задаче маскирования. На сколько я понял по описанию, требуется глазами отследить, где логируются данные, которые нужно скрывать. И проконтролировать их скрытие самостоятельно.
Мне показался такой путь трудным и ненадёжным. Поэтому в Eclair можно помимо ручного выбора формата для распечатки привязать
ru.tinkoff.eclair.printer.Printerк типу аргумента (на весь контекст) и этот принтер будет выполнять свою работу в любом месте приложения, уже без ручного контроля.Пользоваться aspect4log, оговорюсь, не приходилось. И во время разработки Eclair я о таком инструменте не знал, поэтому могу оценивать слишком поверхностно.
ru.tinkoff.eclair.logger.ManualLogger— это не отдельный бин, а interface, который реализован включенным в автоконфигурацию EclairLogger'ом.В примере приведено внедрение через interface. Default'ный логгер его реализует, но делать это не обязательно.
Если сравнивать с
@Slf4j, на ум приходят такие отличия:1) Eclair включает имя логируемого метода в имя логгера (не только при ручном логировании, а вообще всегда), например:
ru.tinkoff.eclair.example.Example.simpleБлагодаря этому есть возможность настраивать через конфигурацию уровни доступного лога не только для пакета/класса, но и для отдельных методов.
Это бывает полезно, когда точно знаешь, в каком месте нужно повысить подробность лога до DEBUG или TRACE, но включать DEBUG для всего класса нет желания (из-за больших объёмов лога или проседания скорости).
2)
ManualLoggerимеет набор «сахарных» методов, напримерManualLogger#warnIfDebugEnabled("some").Такой метод может быть полезен, если в логике обрабатывается некоторое предупреждение (warning), которое не слишком важно, но если для текущей локации доступен DEBUG, то его нужно залогировать как WARN.
Того же можно добиться с помощью
@Slf4j, но менее лаконично:if (log.isDebugEnabled()) { log.warn("some"); }3) ManualLogger принимает в качестве аргументов
Supplier'ы. На сколько я понимаю, в зависимости о того, что лежит «под» @Slf4j-логгером, ты не всегда имеешь возможность провернуть «ленивую» инициализацию аргументов.4) В метод
ManualLogger#logесть возможность передать LogLevel, определяемый динамически. Это тоже для особых ценителей. Не сказать, что сильно важная способность.Если эти способности не востребованы, и достаточно стандартного интерфейса slf4j, а также сам Lombok не является проблемой, вполне можно ограничиться
@Slf4j.