[logback-dev] Organizing loggers per function/mechanism rather than per class

[Cristian SPIESCU]

Hello all,

I would like to change the way messages are logged in my current application. Now, all the loggers are defined in the "classic" way: a logger per class, that is named according to the owning class.

For the features/functions/mechanisms that span their execution among multiple classes, it's more convenient to organize the log per those specific roles that they play in the application. Let me give you an example.
* Class: ServerEndpoint having 2 methods: deserialize(), executeLogic().
* Class: ServerLogicUnit having 2 similar methods: deserialize(), executeLogic().

I'd like both methods: ServerEndpoin.deserialize() and ServerLogicUnit.deserialize() (+ subclasses eventually) to use a logger, let's say: "server.processing.deserialization". In a similar way, ServerEndpoint.executeLogic() and ServerLogicUnit.executeLogic() would use "server.processing.execution".

I see 2 solutions for this. 

1) Have loggers that are registered like this: 


static public Logger loggerSerialization = LoggerFactory.getLogger("server.processing.deserialization"); 
static public Logger loggerExecution = LoggerFactory.getLogger("server.processing.execution"); 


This loggers are stored somewhere kind of globally, and different pieces of code, from various classes use them for logging. 

2) I guess a solution can be found, even if the loggers are stored per class, using markers or MDC + some custom filtering logic. 


My question: what are the best practices in this area? Are there possible issues if I'll go for "Solution 1"?

I'm realizing that I instantiate one logger per class somehow by reflex, not as result of a need. When I need to activate the log in a production application, to see what happens with a certain mechanism of the application, I end up in enabling debug or trace for the whole app. This shows me what I need, but it pollutes my log terribly.

Thank you in advance for you feedback.

Best regards,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-dev/attachments/20120730/ef6fbe3e/attachment.html>