It seems like you have already made up your mind. That’s fine if that is what you want to do. It just is using the system differently than the way we would recommend.
The idea with a Marker is that you can create a global Marker filter for BUSINESS where you would have onMatch=ACCEPT. if you do that then everything logged with a BUSINESS marker will be passed to its appropriate appenders regardless of the events logging level - which is what you asked for. In addition, you can create child markers of BUSINESS, such as FINANCIAL, LEGAL, HR, etc. Since all of these have BUSINESS as their parent they will all be accepted since they will match the marker filter. Again, the intent of markers is to add meta-data regarding what an event is about. The level is a measure of how important the event is. So using a level of Business doesn’t really make sense since you have no idea whether it is more important or less important than any other level. Ralph > On Aug 31, 2015, at 3:02 PM, Nicholas Duane <nic...@msn.com> wrote: > > But ideally I don't want to have to know about org.hibernate unless I need to > do something special for it. Ideally I set up my appenders in <root> and set > the level. One appender handles everything less specific than INFO. Another > appender handles everything between INFO and FATAL, another appender handles > our custom level. > > Everyone logs as they've done before, assuming they're currently logging all > levels through their own logger. At least this is what I had envisioned. It > seems the simplest approach to me. Though I'm new to log4j so what do I know. > > It's unlikely you would have everyone use the same logger for levels less > than INFO because then you couldn't turn certain sections of code from > logging these trace events on or off, unless you also required they use these > markers or some other mechanism. I would rather each use their own logger > and if we find we're getting a bunch of garbage from all org.foobar > components they we can turn them all off. > > Thanks, > Nick > >> Subject: Re: approach for defining loggers >> From: ralph.go...@dslextreme.com >> Date: Mon, 31 Aug 2015 08:50:58 -0700 >> To: log4j-user@logging.apache.org >> >> A logging “Level” is a level of importance. That is why there is a >> hierarchy. If you want informational messages then you also would want >> warnings and errors. >> >> “BUSINESS” does not convey the same meaning. Rather, it is some sort of >> category, which is what Markers are for. >> >> Using the class name as the logger name is a convention. If you really want >> the class name, method name or line number then you should be specifying >> that you want those from the logging event, rather than the logger name. >> Unless location information is disabled you always have access to that >> information. >> >> In short, different loggers are used primarily as a way of grouping sets of >> messages - for example all org.hibernate events can be routed to a specific >> appender or turned off en masse. Levels are used to filter out noise across >> a set of logging events. Markers are used to categorize logging events by >> arbitrary attributes. >> >> Ralph >> >> >>> On 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 >>>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
