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