Java 防止SessionScoped bean中CDI注入记录器的序列化

Java 防止SessionScoped bean中CDI注入记录器的序列化,java,logging,cdi,slf4j,xrebel,Java,Logging,Cdi,Slf4j,Xrebel,自从我开始使用XRebel以来,我一直在想以下几点: 我们开始从以下位置替换记录器(SLF4J)字段: private static final Logger log = LoggerFactory...; 到 使用相应的@生产商生产商 一般来说,这很好,但我想知道@SessionScopedbean的大小。他们现在总是有一个自己的记录器,根据XRebel的数据,每一个豆子都增加了大约900k 现在,SLF4JLoggerFactory.getLogger(clazz类) 返回与作为参数传递的

自从我开始使用XRebel以来,我一直在想以下几点:

我们开始从以下位置替换记录器(SLF4J)字段:

private static final Logger log = LoggerFactory...;

使用相应的
@生产商
生产商

一般来说,这很好,但我想知道
@SessionScoped
bean的大小。他们现在总是有一个自己的记录器,根据XRebel的数据,每一个豆子都增加了大约900k

现在,SLF4J
LoggerFactory.getLogger(clazz类)

返回与作为参数传递的类对应的名为的记录器, 使用静态绑定的iLogger工厂实例

但我不太确定这两者是如何结合在一起的


因此,我的问题是:容器是否真的在每个会话bean的每个实例中都有一个记录器,从而在会话大小上产生相当大的开销,或者使用
@Inject
变量而不产生所有的开销是否安全?

回答您的问题是肯定的-这取决于具体情况

如果将记录器的作用域设置为会话作用域,则为“是”,则每个会话都有自己的记录器。该记录器需要是可序列化的(它们通常不是,因为它们后面有文件句柄)


除了拥有自己的logger facade之外,我所做的是将它们限定在应用程序范围内。通常在场景的后面,记录器是高度同步的(多个调用者向一个附加器写入),更改会排队并定期写入。您可以使用应用程序范围的记录器,这将大大减少超负荷。

我很好奇,您为什么要这样做?注入记录器有什么好处?@JohnAment好吧,这不是我的主意,我仍然坚持使用
private static final
方法,但是-我引用-“因为那些CDI记录器使代码更具可读性”这就是我们现在的做法。无论如何,我仍然不确定CDI方法是否会产生更多的会话开销…顺便说一句,您能否澄清您的生产者方法是否声明了一个作用域。@JohnAment生产者方法没有声明一个作用域:
@产生公共静态记录器getLogger(InjectionPoint InjectionPoint){返回LoggerFactory.getLogger(InjectionPoint.getMember().getDeclaringClass();}
我无法用
@ApplicationScoped
对该方法进行注释,Eclipse给了我一些错误:声明@Dependent以外的任何作用域的Bean有一个类型为InjectionPoint和限定符@Default的注入点[JSR-299§5.5.7]@JohnAment:一个注入的记录器是否有助于允许记录器在每个日志条目上自动包含会话信息(例如,格式化日志条目以包含用户id或购物车的当前大小等)?
@Inject
private Logger log;