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. > 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
