Will SLF4J's Logger get vararg methods soon? Please?
--jason
On May 6, 2008, at 4:15 PM, Ceki Gulcu wrote:
Jason Dillon <[EMAIL PROTECTED]> writes:
The other option, is to create our own SLF4J implementation, which
provides this serialization muck... which may also allow us to add
some ability to inject some state into the MDC and/or NDC to provide
more details about the logger, like which plugin or which ear they
came from, etc...
--jason
On May 6, 2008, at 1:13 AM, Jarek Gawor wrote:
Jason,
I think we need a better solution then changing the code to have
static loggers. There is tons of code that does
LoggerFactory.getLogger(getClass()); and so unless we update all of
the code to use static loggers, sooner or later this problem with
seralization will bite us again. So I think we will need a way for a
logger to serialize/deserlialize ok and at the same time continue to
update the code to use static loggers.
Jarek
I think that Jason's proposal to inject contextual information about
the logger via MDC is really very good. I'd be happy to support
context injection via MDC should the need arise.
Jarek's observation about tons of code using the
LoggerFactory.getLogger(getClass()) idiom may be true for geronimo but
is probably not true generally. The more common idiom declares loggers
as static members.
Moreover, keep in mind that loggers in all underlying implementations,
including j.u.l, log4j and logback, are not intended to survive
serialization. Thus, you may render your own implementation of SLF4J
logger serializable, but I don't see how the underlying loggers would
become serializable.
As far as I can tell, context injection via MDC plus static loggers
should meet most needs without creating complications.
