RE: approach for defining loggers

[Nicholas Duane]

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

Re: approach for defining loggers

[Gary Gregory]

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

Re: approach for defining loggers

[Ralph Goers]

A logging “Level” is a level of importance. That is why there is a hierarchy. 
If you want informational messages then you also would want warnings and errors.

“BUSINESS” does not convey the same meaning.  Rather, it is some sort of 
category, which is what Markers are for.

Using the class name as the logger name is a convention. If you really want the 
class name, method name or line number then you should be specifying that you 
want those from the logging event, rather than the logger name.  Unless 
location information is disabled you always have access to that information.

In short, different loggers are used primarily as a way of grouping sets of 
messages - for example all org.hibernate events can be routed to a specific 
appender or turned off en masse. Levels are used to filter out noise across a 
set of logging events. Markers are used to categorize logging events by 
arbitrary attributes.

Ralph


> On Aug 31, 2015, at 8:10 AM, Nicholas Duane  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  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 

Re: approach for defining loggers

[Gary Gregory]

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

RE: approach for defining loggers

[Nicholas Duane]

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

Re: approach for defining loggers

[Gary Gregory]

For good or bad, a simple way folks use logger is one per class (in a final
static var). This can give you 100's or 1000's of loggers in a large app.
I've even see apps that use per-instance loggers, so that, for example, in
a server, each is named
com.example.requests.DoThis, com.example.requests.DoThat and so on.

When you have 100s of loggers, it can be hard to get the system to log just
what you need, but hierarchical loggers help here.

There's just no way to get around using a third party's logging naming like
the org.hibernate example you mention.

My experience is that splitting up your logging with appenders per levels
in only useful to split out FATAL and ERROR (and maybe WARN) levels. You
usually do not want to always log TRACE for example, because this can have
serious performance implications. For example, in some of my projects,
TRACE logging logs hex dumps for our on-the-wire network traffic.

This is one of the reasons I use FLOW markers to mark TRACE of API calls vs
another marker BUFFER used when hex dumps are logged at the TRACE level.

You might think that using a FLOW log level would be an alternative, but
would that be more or less detailed than TRACE? With markers, you do not
have to decide or worry about it.

Gary

On Mon, Aug 31, 2015 at 3:02 PM, Nicholas Duane  wrote:

> But ideally I don't want to have to know about org.hibernate unless I need
> to do something special for it.  Ideally I set up my appenders in 
> and set the level.  One appender handles everything less specific than
> INFO.  Another appender handles everything between INFO and FATAL, another
> appender handles our custom level.
>
> Everyone logs as they've done before, assuming they're currently logging
> all levels through their own logger.  At least this is what I had
> envisioned.  It seems the simplest approach to me.  Though I'm new to log4j
> so what do I know.
>
> It's unlikely you would have everyone use the same logger for levels less
> than INFO because then you couldn't turn certain sections of code from
> logging these trace events on or off, unless you also required they use
> these markers or some other mechanism.  I would rather each use their own
> logger and if we find we're getting a bunch of garbage from all org.foobar
> components they we can turn them all off.
>
> Thanks,
> Nick
>
> > Subject: Re: approach for defining loggers
> > From: ralph.go...@dslextreme.com
> > Date: Mon, 31 Aug 2015 08:50:58 -0700
> > To: log4j-user@logging.apache.org
> >
> > A logging “Level” is a level of importance. That is why there is a
> hierarchy. If you want informational messages then you also would want
> warnings and errors.
> >
> > “BUSINESS” does not convey the same meaning.  Rather, it is some sort of
> category, which is what Markers are for.
> >
> > Using the class name as the logger name is a convention. If you really
> want the class name, method name or line number then you should be
> specifying that you want those from the logging event, rather than the
> logger name.  Unless location information is disabled you always have
> access to that information.
> >
> > In short, different loggers are used primarily as a way of grouping sets
> of messages - for example all org.hibernate events can be routed to a
> specific appender or turned off en masse. Levels are used to filter out
> noise across a set of logging events. Markers are used to categorize
> logging events by arbitrary attributes.
> >
> > Ralph
> >
> >
> > > On Aug 31, 2015, at 8:10 AM, Nicholas Duane  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
> > >>
> > >>
> 

Re: approach for defining loggers

[Gary Gregory]

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

> On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane  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  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 
>> 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 

RE: approach for defining loggers

[Nicholas Duane]

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 
> wrote:
> 
> > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane  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  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 
> >> 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 

Re: approach for defining loggers

[Remko Popma]

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

RE: approach for defining loggers

[Nicholas Duane]

Your example sounds reasonable.
 
Thanks,
Nick
 
> Subject: Re: approach for defining loggers
> From: remko.po...@gmail.com
> Date: Tue, 1 Sep 2015 07:57:57 +0900
> To: log4j-user@logging.apache.org
> 
> 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  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  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  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. 

RE: approach for defining loggers

[Nicholas Duane]

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  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 
> > > wrote:
> > >
> > > > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane 
> > 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 
> > 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