Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should we keep ?

[Ceki Gülcü <ce...@qos.ch>]

Emmanuel Lécharny wrote:
 > The way it was done in MINA was awfull : the log level ws always set
 > to debug, and we overriden this level with our own level :
 >
 > if ( requestedLevel == DEBUG ) { Log.debug( blah ); }

Looking at LoggingFilter [1] and IOFilter [2], it looks like you have
found a workaround for the lack of a log method in org.slf4j.Logger
taking a level as parameter.

FYI, org.slf4j.Logger has support for Markers which can be used to add
meta-data to logging statements. You could define a markers for events
related to exceptionCaught, messageSent, messageReceived,
sessionCreated and so on. Moreover, since markers are actually
non-cyclic graphs, you could have all the previous markers reference a
generic MINA marker. Thus, he exceptionCaught marker would reference
the MINA marker. Same for messageSent and so on.

You could take the exercise one step further and have filter specific
markers. For example, the filter for protocol X, could define a marker
PROTOCOL_X and and for some event, say sessionCreated, create a marker
referencing 3 markers: MINA, sessionCreated and the PROTOCOL_X marker.

To complete the picture, logback supports filtering based on
markers. So you could enable logging for the messageSent event for all
filters, disable logging for protocol Y and enable it for protocol Z.

You might not want to have complex logging filters, but with the help
of markers, if you wanted to, you could.

My point is that once you can come up with a reasonable logging
strategy, it can be implemented in logback using markers. Moreover,
since markers are part of the SLF4J client API, logging frameworks
lacking marker support, e.g. log4j or j.u.l., would fallback to the
regular logger-level filtering without any prejudice to the end-user.

BTW, logback is now dual-licensed under both the LGPL and the EPL.

Cheers,

[1] http://tinyurl.com/ybrbzw2
[2] http://tinyurl.com/y9h2vjn