RE: approach for defining loggers

[Nicholas Duane]

I will certainly look them over again.
Thanks,Nick

 Original message 
From: Ralph Goers 
Date: 09/07/2015  9:39 PM  (GMT-07:00)
To: Log4J Users List 
Subject: Re: approach for defining loggers

I still don’t understand why you don’t want to use Markers. They were designed 
exactly for the use case you are describing.

You might set retention policies for debug vs info, error and fatal, but a 
BUSINESS marker could cross-cut them all.  That is exactly why it is NOT a 
level. IOW, it gives you a second dimension for filtering. Ceki invented 
Markers when he created SLF4J. For his point of view see 
http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
 
.

Ralph




> On Sep 7, 2015, at 5:54 PM, Nicholas Duane  wrote:
>
> If I'm attempting to control all the logging from the configuration and I 
> don't know the complete set of loggers in my application as there could be 
> 100's or 1000's, wouldn't it be hard to separate events based on loggers?  It 
> would seem much easier to separate events based on level.  In addition, level 
> might be a more reasonable approach for separating.  For example, if I want 
> to send all events to some big-data backend I might want to separate out 
> traces and debug from info to fatal as traces and debug are most likely less 
> important from a systems management aspect.  My retention period for traces 
> and debug might be just a couple days.  The retention period for info to 
> fatal could be 30 days.  Business level might be 2 years.  Any system 
> management notifications would probably be driven off of info to fatal events 
> and not trace and debug events, which is another reason you might want to 
> separate by level.
>
> 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


> 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 

Re: approach for defining loggers

[Ralph Goers]

I still don’t understand why you don’t want to use Markers. They were designed 
exactly for the use case you are describing.  

You might set retention policies for debug vs info, error and fatal, but a 
BUSINESS marker could cross-cut them all.  That is exactly why it is NOT a 
level. IOW, it gives you a second dimension for filtering. Ceki invented 
Markers when he created SLF4J. For his point of view see 
http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
 
.

Ralph




> On Sep 7, 2015, at 5:54 PM, Nicholas Duane  wrote:
> 
> If I'm attempting to control all the logging from the configuration and I 
> don't know the complete set of loggers in my application as there could be 
> 100's or 1000's, wouldn't it be hard to separate events based on loggers?  It 
> would seem much easier to separate events based on level.  In addition, level 
> might be a more reasonable approach for separating.  For example, if I want 
> to send all events to some big-data backend I might want to separate out 
> traces and debug from info to fatal as traces and debug are most likely less 
> important from a systems management aspect.  My retention period for traces 
> and debug might be just a couple days.  The retention period for info to 
> fatal could be 30 days.  Business level might be 2 years.  Any system 
> management notifications would probably be driven off of info to fatal events 
> and not trace and debug events, which is another reason you might want to 
> separate by level.  
> 
> 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
 
 
> 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 

Re: approach for defining loggers

[Gary Gregory]

Don't forget that loggers can be controlled by their hierarchical names:
com.example = DEBUG, usually sets all levels below it to DEBUG, like
com.example.feature1.sub1, com.example.feature1.sub2, com.example.feature2,
and so on.

Gary

On Mon, Sep 7, 2015 at 5:54 PM, Nicholas Duane  wrote:

> If I'm attempting to control all the logging from the configuration and I
> don't know the complete set of loggers in my application as there could be
> 100's or 1000's, wouldn't it be hard to separate events based on loggers?
> It would seem much easier to separate events based on level.  In addition,
> level might be a more reasonable approach for separating.  For example, if
> I want to send all events to some big-data backend I might want to separate
> out traces and debug from info to fatal as traces and debug are most likely
> less important from a systems management aspect.  My retention period for
> traces and debug might be just a couple days.  The retention period for
> info to fatal could be 30 days.  Business level might be 2 years.  Any
> system management notifications would probably be driven off of info to
> fatal events and not trace and debug events, which is another reason you
> might want to separate by level.
>
> 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
> > >>
> > >>
> > >>> 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 

RE: approach for defining loggers

[Nicholas Duane]

Yeah, I'm aware of that feature in log4j/log4net.  Very nice one by the way.  
One of the big pluses in my mind.  Makes it very easy to control a while slew 
of loggers based on name.
 
Though in our case we probably won't know many, if any, of the logger names.  
We basically want to direct all traces to one location, all info to fatal to 
another location and business events to yet a third location.
 
Thanks,
Nick
 
> Date: Mon, 7 Sep 2015 18:35:13 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> Don't forget that loggers can be controlled by their hierarchical names:
> com.example = DEBUG, usually sets all levels below it to DEBUG, like
> com.example.feature1.sub1, com.example.feature1.sub2, com.example.feature2,
> and so on.
> 
> Gary
> 
> On Mon, Sep 7, 2015 at 5:54 PM, Nicholas Duane  wrote:
> 
> > If I'm attempting to control all the logging from the configuration and I
> > don't know the complete set of loggers in my application as there could be
> > 100's or 1000's, wouldn't it be hard to separate events based on loggers?
> > It would seem much easier to separate events based on level.  In addition,
> > level might be a more reasonable approach for separating.  For example, if
> > I want to send all events to some big-data backend I might want to separate
> > out traces and debug from info to fatal as traces and debug are most likely
> > less important from a systems management aspect.  My retention period for
> > traces and debug might be just a couple days.  The retention period for
> > info to fatal could be 30 days.  Business level might be 2 years.  Any
> > system management notifications would probably be driven off of info to
> > fatal events and not trace and debug events, which is another reason you
> > might want to separate by level.
> >
> > 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
> > > >>
> > > >>
> > > >>> 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