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 logs stuff about initialization and for example when another component subscribes to market data. The second (RAW_FEED) one logs every market data event as it comes off the wire to a separate file (via a separate appender). This allows us to switch the RAW_FEED off on some systems and on on others. I suggest you simply do what achieves your goals. If there are multiple options then choose the one that is easiest for your team to maintain. Sent from my iPhone > On 2015/09/01, at 7:07, Nicholas Duane <nic...@msn.com> wrote: > > 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? > > Thanks, > Nick > >> Date: Mon, 31 Aug 2015 15:02:09 -0700 >> Subject: Re: approach for defining loggers >> From: garydgreg...@gmail.com >> To: log4j-user@logging.apache.org >> >> 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 >> "what it is I am telling this audience", which is where I use loggers. To >> tell who comes in and out of the system, I have logging in the >> authentication module. To tell what kind of SQL goes to the database, I >> have DEBUG logging in my DB interface code. >> >> I think that once you start chasing down issues and bugs, and writing code >> to help you do that, then it might become more obvious, as to what to do. >> >> Gary >> >>> On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <nic...@msn.com> wrote: >>> >>> I did look through a bit of documentation on markers: >>> >>> https://logging.apache.org/log4j/2.0/manual/markers.html >>> >>> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them >>> >>> My initial impression is that I don't want to use markers. What I'd like >>> to be able to say is: >>> >>> "log the way you have been logging in the past. You don't need to know >>> about any special loggers. Use your own. Here is a new level for our new >>> type of "event". Use that to log this new event." >>> >>> I guess I'm not understanding your vernacular in terms of levels. In my >>> mind the different levels also define different "types" of events. For >>> instance, DEBUG and less specific I would see as tracing type events which >>> are non-functional in nature. They are purely for understanding the call >>> flow, or for performance gathering, or detailed diagnosis. Those could be >>> turned off totally without having much impact on system management. The >>> same can't be said for FATAL to INFO. These levels should always be on so >>> that you can properly manage the system. >>> >>> Thanks, >>> Nick >>> >>>> Date: Mon, 31 Aug 2015 08:37:25 -0700 >>>> Subject: Re: approach for defining loggers >>>> From: garydgreg...@gmail.com >>>> To: log4j-user@logging.apache.org >>>> >>>> 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 >> >> >> >> -- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
