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! :) _______________________________________________ user mailing list [email protected] http://www.slf4j.org/mailman/listinfo/user
