RE: approach for defining loggers

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,

Re: approach for defining loggers

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

Re: approach for defining loggers

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

Re: approach for defining loggers

I think of levels as "how important is this" and "who needs to know this". Some of the art of logging is deciding who you audience is. To help your development team chase down a bug, you want to make sure that the app logs interesting events at the DEBUG and TRACE level. This is different that

RE: approach for defining loggers

All sounds reasonable to me. I'm not sure any of the statements you made go against anything I have stated. Please let me know if you think otherwise. In your authentication module, you log all levels through its logger, right? You don't use separate loggers to log different levels do you?

Re: approach for defining loggers

For good or bad, a simple way folks use logger is one per class (in a final static var). This can give you 100's or 1000's of loggers in a large app. I've even see apps that use per-instance loggers, so that, for example, in a server, each is named com.example.requests.DoThis,

Re: approach for defining loggers

All of this makes me think we need docs for users new to logging... Gary On Mon, Aug 31, 2015 at 3:16 PM, Gary Gregory wrote: > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane wrote: > >> All sounds reasonable to me. I'm not sure any of the statements

RE: approach for defining loggers

While I'm new to log4j I would say I'm not new to logging. We've written our own logging framework 14 or so years ago. It was on the Microsoft platform and was originally targeting the unmanaged world. We later wrote a managed wrapper on it so we could use it from .NET. Most of the events

Re: approach for defining loggers

Not sure that I understand your use case, so let me give a concrete example of how I use loggers. At work I have a component that is responsible for handling marketdata. This component has two loggers: one that uses the component class name as its name, another called "RAW_FEED". The first

RE: approach for defining loggers

Your example sounds reasonable. Thanks, Nick > Subject: Re: approach for defining loggers > From: remko.po...@gmail.com > Date: Tue, 1 Sep 2015 07:57:57 +0900 > To: log4j-user@logging.apache.org > > Not sure that I understand your use case, so let me give a concrete example > of how I use

RE: approach for defining loggers

And I agree. Just letting you know I'm not a total noob when it comes to logging, just log4j and log4net are new to me. Thanks, Nick > Date: Mon, 31 Aug 2015 15:56:40 -0700 > Subject: Re: approach for defining loggers > From: garydgreg...@gmail.com > To: log4j-user@logging.apache.org > >