Hi Nick, Creating a single new level is seldom the right solution IMO. It's not like you are missing a level of granularity (we have custom level examples that demonstrate that, like a VERBOSE level that sits between INFO and DEBUG). It sounds like you need to use _hierarchical_ loggers and/or markers.
The fact that the level is called BUSINESS is also a hint that a level is not quite right because it does not fit in the Level vernacular (INFO, WARN, and so on). If you needed a different set of levels, that would be another story (like the DEFCON levels example). Gary On Mon, Aug 31, 2015 at 8:10 AM, Nicholas Duane <nic...@msn.com> wrote: > Thanks for the feedback. I will look into Markers and MDC. > > With respect to using a separate logger, it would seem I would lose the > information about what application code, eg. the class logger, is sourcing > the event. We would like to have this information. On top of that, it > seems odd, maybe to me only, that for this new level we have our own > logger. It seemed reasonable to me that this new event we want to capture > is just a new level. Just like a DEBUG event is different from an INFO > event. If I define a BUSINESS level why would that not follow the same > design as the current levels? You wouldn't suggest having different > loggers for TRACE DEBUG INFO WARN ERROR FATAL, would you? I think one of > the reasons someone on our side is suggesting I have separate loggers is > that they think the overhead of filtering at the appender is going to have > a noticeable impact. Our plan, at least the one I have now in my head, is > that we'll have some number of appenders in the root. We'll then filter x > < INFO events to a tracing appender, INFO <= x <= FATAL to a logging > appender, and our custom level will go to another appender. Thoughts? > > Thanks, > Nick > > > Subject: Re: approach for defining loggers > > From: ralph.go...@dslextreme.com > > Date: Sat, 29 Aug 2015 20:59:36 -0700 > > To: log4j-user@logging.apache.org > > > > > > > On Aug 29, 2015, at 7:44 PM, Nicholas Duane <nic...@msn.com> wrote: > > > > > > I'm curious if there is a prescribed approach to defining loggers. > Let me state what my assumption is. I assume that normally if some piece > of code wants to log events/messages that it should create a logger for > itself. I guess a reasonable name to use is the class name itself. In > terms of logger configuration I would expect that no loggers are specified > in the log4j configuration UNLESS is needs settings other than the > default. The root logger would specify the default settings, eg. level and > appenders. If some piece of code tied to a logger needs to enable tracing > in order to debug an issue then you would add that logger to the > configuration and set the level less specific for that logger. Is this a > typical and reasonable approach? > > > > What you describe here is the common convention. It is a reasonable > approach. > > > > > > > > I asked because we have the need for a new type of event. To have > this event flow to where we want it to flow the plan is to have a custom > level and have all events at that level captured by a specific appender. > My assumption was that for existing applications we'd just need to add our > appender to the root and add our custom level. The app would need to be > modified to log our new event at the custom level. However, someone > suggested that we could also create a separate logger for this event. My > thinking is that while we don't ever want to turn off logging of this > event, loggers represent "event sources", e.g the code raising the events > and thus having multiple different pieces of code use the same logger > wouldn't allow you to turn on/off logging from those different sections of > code independently. I think the current configuration includes all the > loggers. Normally I would expect there to be many, on the order of 10's or > 100's, loggers within an application. However, in the case I was given > there were only a handful because I think this handful is shared. So as I > mentioned, this doesn't sound like an ideal design as you have less > granularity on what you can turn on/off. > > > > You have a few options. Using a CustomLevel would not be the option I > would choose. Creating a custom Logger will certainly work and makes > routing the message to the appropriate appender rather easy. Another > approach is to use Markers. Markers are somewhat hierarchical so you can > use them for a variety of purposes. If you look at how Log4j handles event > logging it actually does both - it specifies EventLogger as the name of the > logger to use and it uses Markers to identify the kind of event. > > > > A third option is to use the MDC or Logger properties. If you do that > then you can have information included in the actual logging event that can > affect how it is routed. I also built a system that uses the RFC5424 format > so that the event could have lots of key/value pairs to identify the events. > > > > Unfortunately, without knowing more details I don’t know that I can give > you a better idea on how I would implement it. > > > > Ralph > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
