Roger that. I'm just wondering how we can better serve visitors to the site...
Gary On Mon, Aug 31, 2015 at 3:47 PM, Nicholas Duane <nic...@msn.com> wrote: > 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 > flow through ETW and end up in log files which are then Ftp'd to a central > location. > > Thanks, > Nick > > > Date: Mon, 31 Aug 2015 15:38:55 -0700 > > Subject: Re: approach for defining loggers > > From: garydgreg...@gmail.com > > To: log4j-user@logging.apache.org > > > > 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 <garydgreg...@gmail.com> > > wrote: > > > > > 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 | 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
