Комментарии 38
Мне кажется логгер нужно получать по месту ИМХО.
Ибо уровень логирования в настройках указать на package проще будет.
Ибо уровень логирования в настройках указать на package проще будет.
+7
Плюсану, всегда использовал что-то типа
Также подход автора не позволит логировать из static методов.
class SomeCls {
private final Logger log = Logger.getLogger(SomeCls.class);
}
Также подход автора не позволит логировать из static методов.
+2
Зато позволит весело словить NPE — если вызов логера произойдет до связывания.
+9
Не уверен, что это возможно. Спринг бины иницилизирует при старте контексте(кроме lazy).
0
статические инициализаторы, конструкторы класса, сеттеры — все останется без логирования, в юнит-тестах придется инжектить еще и мок-логгер
+3
Не очень понял, зачем бин для логгера? в тексте не увидел пояснений, которыми руководствуется автор. И сохраняется ли при этом разделение уровней логирования по пакетам/классам?
В IDEA у себя держу следующий шаблон, который генерит код для Slf4J:
но в последнее перебрался на аннотацию @Slf4j из Lombok
В IDEA у себя держу следующий шаблон, который генерит код для Slf4J:
@SuppressWarnings("unused")
private static final transient Logger LOG = LoggerFactory.getLogger(CURRENT_CLASS.class.getName());
но в последнее перебрался на аннотацию @Slf4j из Lombok
+2
Зачем static field у вас transient? Они же вроде несереализуемые.
+3
НЛО прилетело и опубликовало эту надпись здесь
это не для защиты против обхода, а скорее для тех, кто смотрит только на transient и не смотрит на static. А в целом не понятно — что плохого в такой избыточности?
0
Не знаю насколько это плохо, но если ваш сериализатор сериализует static, то скорее всего нужно дать по шее разработчику этого сериализатора. ИМХО static field никакого отношения к вашим объектам иметь не должны. В этом я даже одобряю scala подход к разделение на class и object.
+1
НЛО прилетело и опубликовало эту надпись здесь
@Slf4j на сколько я помню создает логгер по названию класса, а если необходимо создавать по имени — то не подойдет. Другой вопрос кому как удобнее получать логгер — по классу или по имени, лично у меня есть примеры когда в одних случаях удобнее первый подход, есть когда второй — тут вопрос как личных предпочтений так и зависимости от контекста конкретной задачи =)
0
Стоит отметить, что подход универсален и годится не только для логгеров. Наоборот, имхо, логгеры — не самый удачный пример.
+2
НЛО прилетело и опубликовало эту надпись здесь
0
НЛО прилетело и опубликовало эту надпись здесь
LoggingAnnotationProcessor работает только с `@Logging` аннотацией
Не вижу труда написать аннотацию+процессор, использующую некоторую фабрику, в зависимости от конкретного типа поля с аннтацией.
Хотя, видимо, для общего случая и правда нет необходимости дублировать уже существующую в Спринге фунциональность.
А вот вообще написать несколько процессоров разнообразных аннотаций, декорирующих, скажем, методы, во избежание дублирования кода — идея сама по себе красивая.
0
НЛО прилетело и опубликовало эту надпись здесь
Добро пожаловать в клуб любителей шаблона ServiceLocator :)
А и верно :)
Это же делает AOP.
Точно.
Но и AOP не предел.
А в целом, мне все больше кажется, что уже для каждой заманчивой идеи уже есть своя библиотека, и все самописное окажется велосипедом :)
Тот же Lombok уже упоминали.
Впрочем, все когда-то было велосипедом, пока не стало достаточно популярным :)
0
Верно, в последних версиях Спринга это так.
0
НЛО прилетело и опубликовало эту надпись здесь
Не сталкивался ещё со случаями, когда понадобилось избавиться от Spring и целиком переехать на JavaEE. Можете привести?
P. S. Парень, зарегистрировавшийся с логином Inject, наверно икает :)а нечего служебные слова использовать ;)
+1
НЛО прилетело и опубликовало эту надпись здесь
Видимо, у Спринга нет (а, похоже, и не будет) достойных конкурентов.
Например, мне очень когда-то понравился фреймворк Tapestry в его 5ой версии. Но пока парни пилили версию 5.4, он безнадежно устарел, увы…
Например, мне очень когда-то понравился фреймворк Tapestry в его 5ой версии. Но пока парни пилили версию 5.4, он безнадежно устарел, увы…
0
Автор сам своё творение не использовал что ли…
Class.getDeclaredFields()
может запросто вернуть (и таки возвращает) кучу автогенерируемых полей и только их, т.к. спринг наследует наши классы, а getDeclaredFields()
работает только на один уровень; так что до наших собственных полей дело просто не дойдёт (по крайней мере, не сделает это гарантированно).0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как в Spring logger получить