If you're doing down this way, I would strongly recommend the ability not only to log specific packages, but to be able to set their logging level as well.
For example, from WebSphere: *=info:com.ibm.ws.webcontainer.*=all:com.ibm.ws.wswebcontainer.*=all:com.ibm.wsspi.webcontainer.*=all:HTTPChannel=all:GenericBNF=all or from an eclipse.options file: com.ibm.ws.sca.rapiddeploy.style/debug=true com.ibm.ws.sca.rapiddeploy.style/trace=true com.ibm.ws.sca.rapiddeploy.style/event=true com.ibm.ws.sca.rapiddeploy.style/info=true com.ibm.ws.sca.headless/debug=true com.ibm.ws.sca.headless/debug/trace=true com.ibm.ws.sca.headless/debug/event=true com.ibm.ws.sca.headless/debug/info=true At this level, you will need to delve into the specifics of formats. Personally, I perfer the WAS style. See: http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/rtrb_enabletrc.html for a better discussion on the formats and syntax. If nothing else, it should provide some food for thought. -Chris On Fri, Nov 16, 2012 at 5:05 AM, Jason van Zyl <[email protected]> wrote: > It looks like Markers[1] are supported in SLF4J and can be used in > conjunction with the class name to gain another axis of control: > > [1] http://www.slf4j.org/apidocs/org/slf4j/Marker.html > > So this is probably the way it should be done as you don't lose the > hierarchy and if you want an additional axis of control you can add > whatever you like. > > On Nov 15, 2012, at 1:02 PM, Benson Margulies <[email protected]> > wrote: > > > 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] > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > the course of true love never did run smooth ... > > -- Shakespeare > > > > > >
