[slf4j-user] Use case for Marker objects

[Endre Stølsvik]

Ceki Gulcu wrote:
> Hello all,
> 
> On the Tapestry mailing list there is an interesting discussion about a probably
> quite fundamental use case for marker objects.
> 
>    http://www.nabble.com/T5%3A-Logging-to14622287.html
> 
> Cheers,
> 

It would be much better if they instead added "tapestry." in front of 
those categories that tapestry use, as suggested by one early poster. It 
seems next to idiotic to let the framework spit out stuff on the same 
category as it is probable that the user will use.

I've never quite gotten why people strictly use the classname as the 
logger's category. In particular for frameworks - having a common prefix 
for all framework messages makes it easy to configure them away, or into 
another sink - or potentially colorize them. Of course, mostly you'll 
have a common prefix: the package name (or the most significant bits of 
it). But in this case at hand, that falls totally through, and it would 
be so much better if all loggers from tapestry stuck "tapestry." or 
"TAPESTRY." or "TAPE." or something in front. That would be JUST as good 
a solution to the problem as markers are - and it would be compatible 
throughout all logging frameworks.

I've never seen the big deal about markers. Using categories a bit more 
cleverly than just sticking the class in there is good enough for most 
use cases (and definitely in this case). If some log message is 
particularly important for two different "contexts", which seems like 
the prime extra-case a marker can fix, it isn't more difficult than to 
output that log line onto both categories (have two Logger instances in 
that class - output to them both for that particular dual-context line).


Off on a tangent: does logback support trace? I'm seriously considering 
abandoning log4j, since sadly its main driving force, Ceki, left the 
building. Logback sounds better, in particular I like the performance 
aspect. One should consider asking those Java Concurrency gurus 
(probably in particular Joshua Bloch, Doug Lea and Brian Goetz) about a 
run-through of the code - it is amazing what they seem to be able to 
come up with (but of course - they just snap their fingers, and suddenly 
the JVM itself has a couple of new concurrency hooks to interface to - a 
nice little Unsafe).

Thanks,
Endre.

PS: I personally make all my Loggers go to a special LoggerCreator - a 
meta-factory of Loggers. All classes do 'private static final Logger log 
= LoggerCreator.getLogger(Class clazz[, String postfix]);' The deal is 
that this class can then decide on the naming system in one single 
place, spitting out different prefixes based on which class name (e.g. 
all "*Test" classes get "PRODUCT.TEST."), interface implementations 
(e.g. all Components get "PRODUCT.COMP."), possibly base class and 
package - or do a special case for one particular class if that is 
required. Most types of classes don't get the fully qualified class name 
- I just use the "simplename", as that along with the mentioned "type" 
is enough to decode/"reverse engineer" where the logline comes from.
   All my own log lines are then clearly distinguished by the prefix 
that all my loggers have, and the different types of classes are also 
clearly visible. As I add a new _type_ of pieces to the product, I just 
update that trivial factory to handle this new type. Changing the entire 
naming scheme of my entire product can be done in one single place.
   I've used this pattern on several projects now, and I've actually 
come to like it a lot - I find it strange that I don't hear about it 
more! :)