防止在SessionScoped Bean中序列化CDI注入的Logger

Question

Since I started to use XRebel, I was wondering about the following:

We started replacing our logger (SLF4J) fields from:

private static final Logger log = LoggerFactory...;

to

@Inject
private Logger log;

with a respective @Produces producer.

This works fine in general, but I was wondering about the size of @SessionScoped beans. They now always have an own logger, adding - according to XRebel - about 900k to every single one of the beans.

Now, the SLF4J LoggerFactory.getLogger(Class clazz) does, according to the docs ,

Return a logger named corresponding to the class passed as parameter, using the statically bound ILoggerFactory instance

But I am not exactly sure, how this plays together.

So my question is: does the container really have one logger in every instance of every session bean, producing quite some overhead in session size, or is it safe to use the @Inject variant without producing all that overhead?

Answer 1

Ok to answer your question - it depends.

If you scope your logger to be session scoped then yes, each session will have its own logger. That logger will need to be serializable (and they typically aren't, since they have file handles behind them).

What I've done - besides having my own logger facade - is to make them application scoped. Typically behinds the scenes loggers are highly synchronized (multiple callers writing to a single appender), changes are queued up and written periodically. You can use an application scoped logger, which will reduce the over head dramatically.