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