Так как я начал использовать XRebel, мне было интересно, о следующем:Предотвращение сериализации CDI впрыскивается Logger в SessionScoped фасолью
Мы начали заменять наши регистратор (SLF4J) полей от:
private static final Logger log = LoggerFactory...;
в
@Inject
private Logger log;
с соответствующим @Produces производитель.
Это нормально работает в целом, но мне было интересно узнать размер бобы @SessionScoped. У них теперь всегда есть собственный регистратор, добавив - согласно XRebel - около 900 тыс. К каждому одному из бобов.
Теперь SLF4J LoggerFactory.getLogger(Class clazz) делает, according to the docs,
Return a logger named corresponding to the class passed as parameter, using the statically bound ILoggerFactory instance
Но я точно не знаю, как это играет вместе.
Итак, мой вопрос: действительно ли в контейнере имеется один регистратор в каждом экземпляре каждого сеансового компонента, что создает некоторые накладные расходы в размере сеанса или безопасно использовать вариант @Inject, не производя все эти накладные расходы?
Мне любопытно, почему вы это делаете? Какую пользу вы получаете от инъекции регистратора? –
@JohnAment хорошо, это была не совсем моя идея, я все равно придерживаюсь этого «частного статического финального» подхода, но - и я цитирую - «потому что эти регистраторы CDI делают код более понятным», это то, что мы имеем Теперь. Во всяком случае, я все еще не уверен, что подход CDI создает дополнительные служебные накладные расходы или нет ... –
Кстати, вы можете уточнить, объявляет ли ваш метод производителя область видимости. –