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
