Gary, your examples are great and would be a good addition to the Introduction page.
Ralph > On Sep 1, 2015, at 3:47 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Tue, Sep 1, 2015 at 3:26 PM, Nicholas Duane <nic...@msn.com > <mailto:nic...@msn.com>> wrote: > >> I was re-reading this and thought I should respond. You mentioned that >> levels are used to indicate the importance of what you logged. The logger >> helps you with "what is it that I'm trying to tell" the audience, if I have >> that correct. Which I kind of agree. The logger, in my mind, indicates >> the "area" of code which is sourcing the events. In your example you have >> an authentication module which has its own logger. All events (hopefully >> using the terms events is ok) logged from that logger has to do with >> authentication. > > > Yes, a "log event" is the right general term, which we happen to use > internally with the interface org.apache.logging.log4j.core.LogEvent. > > The authentication module uses its logger to log events at different >> levels. > > > Right, for example, from the auth Logger: > > INFO - User Alice logged in. > WARN - User Bob entered an invalid password. > ERROR - User Bob entered an invalid password three times and is now locked > out. > > Then from a different part of the app, the email agent Logger, for example: > > DEBUG: Read account for Bob from database connection jdbc://... > INFO - Emailed user Bob that his account might be under attack because > three login attempts were rejected. > ERROR - Email bounced back to al...@example.com <mailto:al...@example.com>; > subject: foo. > > So you can imagine that for different loggers, the meaning of what is > normal vs. an error can be very different. > > Gary > > So in my scenario, the authentication module might want to log a "Business" >> event. In reality this probably would not happen as the business events >> would most likely be sourced from LOB application code. However, each >> component of LOB application code might have its own logger and if it needs >> to log a business event it should do so from its logger. >> >> I did look at markers and it would seem if I used them for these business >> events I would still be logging the business events at some level and would >> include a marker. This seems odd to me as the level would seem pointless >> and thus picking one would be arbitrary. >> >> Someone had mentioned using the EventLogger. I still have to look into >> that, but that sounds like a single logger which I initially thought was >> not required and instead the advice would be to log via whatever logger >> you're using for your other events. However, maybe the EventLogger will >> work. >> >> Thanks, >> Nick >> >> >>> Date: Mon, 31 Aug 2015 15:16:49 -0700 >>> Subject: Re: approach for defining loggers >>> From: garydgreg...@gmail.com >>> To: log4j-user@logging.apache.org >>> >>> On Mon, Aug 31, 2015 at 3:07 PM, 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? >>> >>> >>> Yes. >>> >>> >>>> You don't use separate loggers to log different levels do you? >>>> >>> >>> No separate loggers per levels. >>> >>> Gary >>> >>> >>>> >>>> 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 >>>> >>>> >>> >>> >>> >>> -- >>> 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 <mailto:garydgreg...@gmail.com> | > ggreg...@apache.org <mailto:ggreg...@apache.org> > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ > <http://www.manning.com/tahchiev/>> > Spring Batch in Action <http://www.manning.com/templier/ > <http://www.manning.com/templier/>> > Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> > Home: http://garygregory.com/ <http://garygregory.com/> > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
