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
>
> 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
