[slf4j-dev] Category of Logger vs. name of containing class.

[Ceki Gülcü]

At 02:54 PM 7/11/2005, Endre Stølsvik wrote:

>| But as I think you realize, it is not necessarily the best hierarchy for
>| production environments.
>
>I've never used the classname.

You have never user class names to limit the scope of loggers to their
declaring class? Representation-wise, where do you reckon your usage
pattern falls?

>If I could attach one Logger to "several names", so that if I do
>httpRedUserAuthLog.info("Red User ["+user.getName()+"] has
>authenticated."), the log statement would be injected both on the auth
>category ("Septim.AUTH.user" or whatever, "Septim" being my imaginary
>server), on the server-core category ("Septim.CORE.httphandler" or
>whatever), and on the color category ("Septim.Color.red"), then that might
>be a cool new feature without introducing much extra complexity.
>
>  // Make Logger, with primary, mandatory category
>  Logger httpUserRedAuthLog = Logger.getLogger("Septim.AUTH.user")
>  // Additional categories
>  httpUserRedAuthLog.addCategory("Septim.CORE.httphandler")
>  httpUserRedAuthLog.addCategory("Septim.Color.red")
>
>Logger.addCategory(String extraCat) would thus be the only new API-level
>method..

>The first element here, that this log-statement would end up in three
>different files, is already solved in at least log4j by instead of
>injecting into three categories, one would inject to only the one
>category, and configuring that category to append to all three Appenders.
>   But, with some clever log-configuration and the multiple category
>attachment feature above, I could ALSO state more specifically that I want
>only all "Colored Auth" statements to go to this particluar file.
>   The example might be useless, but in any case, it would maybe solve some
>of the axes-problems? - You basically introduce a new axis by adding a new
>category to several loggers.
>
>However, I realize that this solution has limitation that the Marker
>approach would fix: you cannot switch that easily between red and green
>users, w/o making a lot different colored loggers. So Marker is a nice
>idea, but what about not introducing a new concept, and instead just
>enabling method-specific injections of additional categories?

Given that the two concepts are very similar, if Marker is a new
concept then so is attaching multiple categories to a logger, and vice
versa.


>  // Make Logger, with primary, mandatory category
>  Logger httpUserAuthLog = Logger.getLogger("Septim.AUTH.user")
>  // Additional categories
>  httpUserAuthLog.addCategory("Septim.CORE.httphandler")
>
>  // log line
>  httpUserAuthLog.info("Septim.Color.red", "User ["+user.getName()+"] has
>authenticated.");
>
>.. basically the exact same idea as the current "Marker" approach, but
>that the markers are just additional categories? If there is a problem
>with the log method signatures, then by all means keep the Marker
>interface / simple class, but just as a wrapper around a String denoting
>the category.

That's the idea.

>   It would require versions with 'Marker marker' and 'Marker[] markers' to
>all the log methods - thus obviously multiplying the existing methods by
>three!

If Marker is a composite, then the number of existing methods is
multiplied by two, not three. Although two is still a non-negligible
factor, the impact on existing implementations can be small and
localized, in particular because markers are almost entirely
orthogonal to the current hierarchical logger/level paradigm.


>Regards,
>Endre.

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/