On Thu, Nov 15, 2012 at 11:25 AM, Jason van Zyl <[email protected]> wrote: > > On Nov 15, 2012, at 11:08 AM, Benson Margulies <[email protected]> wrote: > >> I can see arguments on both sides of this question of how to pick the >> logging ID. I'll start with my corner. >> >> The convention of having a logger for each class, named after the >> class, is just that. A convention. It serves well in many cases. >> However, in my opinion, it threatens to become a sort of cargo-cult >> law of nature. >> >> The various logging frameworks all permit arbitrary names (with >> separators) for loggers, and they permit it for a reason. Sometimes, >> there is a good reason to control logging on an axis that is not class >> names. >> > > I have never been limited in any domain specific way by using the class name. > In every single case, without exception, a mapping can be made from something > to the class name to create filters. Doing it differently potentially > interferes with all known ways of doing this. I have never seen something > other than class names be used, and I have also never seen that as a > limitation in any logging context.
Here's the situation I recall in which this came up.. A complex body of code, involving many classes, implements a decoder for an 'averaged perceptron named entity extractor'. In some situations, there are logging messages that allow a developer to monitor how the algorithm is dealing with a particular input. These messages are scattered over many classes, and in these classes, only *some* of the potential logging messages are relevant to the task of tracing the behavior of the decoder. Controlling by class wasn't going to work, because it would end up turning on undesirable noise along with the desired information. Controlling by level would have worked if I was using a logging framework that supported custom levels. It has occasionally struck me as odd that this is a rare feature of logging frameworks. slf4j, for example, precludes it. So, I defined a single 'decoder trace' logger, and made all of these messages post to it. I could then turn these on and off independently of all of the others. When I first responded to this thread, my instinct was to see the G:A:V 'axis' as analogous. As I think about it now, my view is that there is an analogy, but that neither olamy's proposal nor the 'usual thing+map' fixes it. When developing a plugin, I wish that I could make a very clear distinction between two classes of messages: messages that provided additional detail intended for end users, and messages that are only there for developers. Arguably, what I am complaining about is that the existing Mojo logging API has too few levels; I want to distinguish 'error', 'info', 'detail', and 'debug'. Error and info would be displayed by default, 'detail' via (e.g.) -X, and 'debug' by -XX. Pretty clearly, this is orthogonal to the debate at hand, so I'm going to stop typing and see what others have to write. > >> I've had a few occasions where I really wanted to be able to control >> logging on some other logical axis, so I created a logger with some >> suitable name, and I used it in multiple classes. Just as in olamy's >> proposal. >> >> This scheme makes it trivial for us to allow end-users to control >> logging by plugin, since we don't need any additional framework, data >> structure, or mapping. >> >> The other side of the coin, as I see it, is that developers also want >> to do fine-grained logging control, and, in almost all cases, class >> names serve well. So, something like Jason's scheme of using >> conventional class names, but providing a mapping, would appear to >> serve both needs. >> >> However ... the mapping in question seems to me to be inevitably tied >> to the selection of one logging backend, unless we want to invent some >> sort of slf4j-ish means of mapping. I am most familiar with log4j, so >> I'll be concrete with the issue as it would arise there. If we use >> class-name loggers, and provide a mapping that maps from G/AV to >> packages or classes, something has to take this mapping and use it to >> generate a log4j configuration. I presume that the same would apply to >> logback or whatever else. >> >> That seems a lot of work to me. So, my opinion is that olamy's scheme >> is better, because it puts the needs of end-users ahead of the needs >> of devs. >> >> However, if we only care about solving G/A/V control for actual >> end-users of Maven, and not users of complex embeds, then my view gets >> weaker. Once we choose a logging back-end for Apache Maven, it's not >> going to be very hard to implement the control mapping for that one >> back-end. >> >> So, weirdly, I find myself arguing against Jason on behalf of the use >> case he's usually arguing for. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > A man enjoys his work when he understands the whole and when he > is responsible for the quality of the whole > > -- Christopher Alexander, A Pattern Language > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
