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'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]
