Как в Spring logger получить

[xonix]

Плюсану, всегда использовал что-то типа

class SomeCls {
  private final Logger log = Logger.getLogger(SomeCls.class);
}

Также подход автора не позволит логировать из static методов.

[MzMz]

Зато позволит весело словить NPE — если вызов логера произойдет до связывания.

[MzMz]

статические инициализаторы, конструкторы класса, сеттеры — все останется без логирования, в юнит-тестах придется инжектить еще и мок-логгер

[Borz]

Не очень понял, зачем бин для логгера? в тексте не увидел пояснений, которыми руководствуется автор. И сохраняется ли при этом разделение уровней логирования по пакетам/классам?

В IDEA у себя держу следующий шаблон, который генерит код для Slf4J:

@SuppressWarnings("unused")
private static final transient Logger LOG = LoggerFactory.getLogger(CURRENT_CLASS.class.getName());

но в последнее перебрался на аннотацию @Slf4j из Lombok

[Borz]

stackoverflow.com/questions/4565653/java-static-transient-fields

[Borz]

это не для защиты против обхода, а скорее для тех, кто смотрит только на transient и не смотрит на static. А в целом не понятно — что плохого в такой избыточности?

[ruslanys]

Всем рекомендую Lombok и его аннотацию @Sl4j.

[onakrainikoff]

@Slf4j на сколько я помню создает логгер по названию класса, а если необходимо создавать по имени — то не подойдет. Другой вопрос кому как удобнее получать логгер — по классу или по имени, лично у меня есть примеры когда в одних случаях удобнее первый подход, есть когда второй — тут вопрос как личных предпочтений так и зависимости от контекста конкретной задачи =)

[Borz]

она имеет атрибут "topic", где можно переопределить с класса на имя

[onakrainikoff]

отлично, перейду пожалуй на Lombok :)

[Borz]

имеется в виду, что в логгере будет в качестве имени — полный путь до класса или просто некое слово.

[Lure_of_Chaos]

Стоит отметить, что подход универсален и годится не только для логгеров. Наоборот, имхо, логгеры — не самый удачный пример.

[Lure_of_Chaos]

Но для каждого класса придётся объявлять свою аннотацию + процессор

Разве?

И, кстати, хорошо бы вместо @Autowired и Qualifier использовать Inject и Named, а еще бы объединить эти аннотации в одну.

[Lure_of_Chaos]

LoggingAnnotationProcessor работает только с `@Logging` аннотацией

Не вижу труда написать аннотацию+процессор, использующую некоторую фабрику, в зависимости от конкретного типа поля с аннтацией.
Хотя, видимо, для общего случая и правда нет необходимости дублировать уже существующую в Спринге фунциональность.

А вот вообще написать несколько процессоров разнообразных аннотаций, декорирующих, скажем, методы, во избежание дублирования кода — идея сама по себе красивая.

[Lure_of_Chaos]

Добро пожаловать в клуб любителей шаблона ServiceLocator :)

А и верно :)

Это же делает AOP.

Точно.
Но и AOP не предел.

А в целом, мне все больше кажется, что уже для каждой заманчивой идеи уже есть своя библиотека, и все самописное окажется велосипедом :)
Тот же Lombok уже упоминали.
Впрочем, все когда-то было велосипедом, пока не стало достаточно популярным :)

[Borz]

а разве @Autowired и Inject не эквивалентны?

[Lure_of_Chaos]

Верно, в последних версиях Спринга это так.

[Borz]

Не сталкивался ещё со случаями, когда понадобилось избавиться от Spring и целиком переехать на JavaEE. Можете привести?

P. S. Парень, зарегистрировавшийся с логином Inject, наверно икает :)

а нечего служебные слова использовать ;)

[Lure_of_Chaos]

Видимо, у Спринга нет (а, похоже, и не будет) достойных конкурентов.

Например, мне очень когда-то понравился фреймворк Tapestry в его 5ой версии. Но пока парни пилили версию 5.4, он безнадежно устарел, увы…

[Lure_of_Chaos]

Play я ковырял достаточно давно, тогда он меня не впечатлил, особенно тем, что он stateless, а также для раскрытия потенциала нужна scala.

[zencd]

Автор сам своё творение не использовал что ли…
Class.getDeclaredFields() может запросто вернуть (и таки возвращает) кучу автогенерируемых полей и только их, т.к. спринг наследует наши классы, а getDeclaredFields() работает только на один уровень; так что до наших собственных полей дело просто не дойдёт (по крайней мере, не сделает это гарантированно).

[onakrainikoff]

«clazz = clazz.getSuperclass();» дойдет