Re: approach for defining loggers

[Ralph Goers]

See below

> On Sep 11, 2015, at 12:33 PM, Nicholas Duane  wrote:
> 
> I think it's great that you took the time and effort to put this together.  
> Hopefully it will help guide people in the correct direction as they work 
> through these issues.  Hopefully this link is found when they google 'log4j 
> log levels' or 'log4j loggers' etc..
> 
> 1. While your level examples elude to this you don't, as far as I can tell, 
> specifically spell this out.  I guess you're always assuming that level is a 
> gradient or scale.  Meaning if I turn on a specific level I will get events 
> for that level and any level more specific.  Would it be invalid to make 
> level an enumeration and thus level would 'kind of' indicate event 'type’.

All Java logging frameworks that I am aware of view the level as a gradient as 
Gary described it.  If you look at RFC 3164 [1] you will see that unix syslog 
events have a severity that works exactly the same way. This is actually where 
Java logging levels were inspired from. If you look at the documentation for 
syslog [2] you will see mention that this is the way it works on unix systems.  

> 
> 2. Wording problems maybe:
> 
> "What if others log from a third party library log"
> 
> "Now, I can configure Log4j to log only all events"
> 
> 3. In the part about markers you indicate that with a marker you can enable 
> logging for an event no matter what level the event was logged at.  In that 
> case the below statement seems to contradict:
> 
> "Here, start by setting the root logger to WARN, then we set the oven to 
> log at DEBUG because the oven logs door events at the DEBUG level, and 
> the garage to log at INFO because the garage logs door events at the 
> INFO level."
> 
> I thought it shouldn't matter if the over door logs at DEBUG level.  Can't I 
> still set everything to WARN and use a marker to get the event logged?

You can do both.  If you choose to ignore the marker then you can filter only 
by log level.  If you want one appender to handle all the BUSINESS events and 
another appender to handle only warnings and errors (including BUSINESS events) 
you can also do that.  See the configuration I sent you the other day. It only 
separates between those with the marker and those without because that is what 
you asked for. However, I could have given you a configuration that also does 
the second case.

> 
> 4. Your markers section seems geared toward showing how to enable logging of 
> events even if the level is off.  In my specific case, while I would of 
> course need the event to be logged, I want to route specific types (/levels?) 
> of events to specific appenders because different events are going to 
> different locations.

You should be able to extrapolate from the configuration I provided you to be 
able to do this.

Ralph



[1] https://www.ietf.org/rfc/rfc3164.txt 
[2] http://www.rsyslog.com/doc/v8-stable/configuration/filters.html 





> 
>> Date: Thu, 10 Sep 2015 21:21:09 -0700
>> Subject: Re: approach for defining loggers
>> From: garydgreg...@gmail.com
>> To: log4j-user@logging.apache.org
>> 
>> This thread inspired me to explain logging concepts:
>> 
>> https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
>> 
>> I hope it helps!
>> 
>> Gary
>> 
>> On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal 
>> wrote:
>> 
>>> Then perhaps you should create your own facade for doing business event
>>> logging, which could then forward them to Log4j in an appropriate way.
>>> 
>>> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane  wrote:
>>> 
 I was just about to reply to your previous email about using a single
 "business" logger, or some hierarchy of business loggers, to log business
 events and say that we might go that route.  However, now that you
>>> brought
 up the post from Ralph, which I just replied to, I'm thinking a logger
 won't work either for the same reason I listed in my reply to Ralph's
>>> post.
 
 You could do:
 
 logger.info("Hello");
 logger.fatal("Hello");
 logger.error("Hello");
 ...
 
 It's confusing as there are n ways to log a business event that way and
 they will all do the same thing.  Which one should a developer choose.
 Should I say pick any one, it doesn't matter?
 
 Thanks,
 Nick
 
> Date: Tue, 8 Sep 2015 19:28:21 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> Or
> Logger logger = LogManager.getLogger("Business");
> ...
> logger.info("Hello");
> 
> Gary
> 
> On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com>
> wrote:
> 
>> Can you please clarify, “If we had some way to know an 

RE: approach for defining loggers

[Nicholas Duane]

I think it's great that you took the time and effort to put this together.  
Hopefully it will help guide people in the correct direction as they work 
through these issues.  Hopefully this link is found when they google 'log4j log 
levels' or 'log4j loggers' etc..

1. While your level examples elude to this you don't, as far as I can tell, 
specifically spell this out.  I guess you're always assuming that level is a 
gradient or scale.  Meaning if I turn on a specific level I will get events for 
that level and any level more specific.  Would it be invalid to make level an 
enumeration and thus level would 'kind of' indicate event 'type'.

2. Wording problems maybe:

"What if others log from a third party library log"

"Now, I can configure Log4j to log only all events"

3. In the part about markers you indicate that with a marker you can enable 
logging for an event no matter what level the event was logged at.  In that 
case the below statement seems to contradict:

"Here, start by setting the root logger to WARN, then we set the oven to 
log at DEBUG because the oven logs door events at the DEBUG level, and 
the garage to log at INFO because the garage logs door events at the 
INFO level."

I thought it shouldn't matter if the over door logs at DEBUG level.  Can't I 
still set everything to WARN and use a marker to get the event logged?

4. Your markers section seems geared toward showing how to enable logging of 
events even if the level is off.  In my specific case, while I would of course 
need the event to be logged, I want to route specific types (/levels?) of 
events to specific appenders because different events are going to different 
locations.

Thanks,
Nick

> Date: Thu, 10 Sep 2015 21:21:09 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> This thread inspired me to explain logging concepts:
> 
> https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
> 
> I hope it helps!
> 
> Gary
> 
> On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal 
> wrote:
> 
> > Then perhaps you should create your own facade for doing business event
> > logging, which could then forward them to Log4j in an appropriate way.
> >
> > On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane  wrote:
> >
> > > I was just about to reply to your previous email about using a single
> > > "business" logger, or some hierarchy of business loggers, to log business
> > > events and say that we might go that route.  However, now that you
> > brought
> > > up the post from Ralph, which I just replied to, I'm thinking a logger
> > > won't work either for the same reason I listed in my reply to Ralph's
> > post.
> > >
> > > You could do:
> > >
> > > logger.info("Hello");
> > > logger.fatal("Hello");
> > > logger.error("Hello");
> > > ...
> > >
> > > It's confusing as there are n ways to log a business event that way and
> > > they will all do the same thing.  Which one should a developer choose.
> > > Should I say pick any one, it doesn't matter?
> > >
> > > Thanks,
> > > Nick
> > >
> > > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > > Subject: Re: approach for defining loggers
> > > > From: garydgreg...@gmail.com
> > > > To: log4j-user@logging.apache.org
> > > >
> > > > Or
> > > > Logger logger = LogManager.getLogger("Business");
> > > > ...
> > > > logger.info("Hello");
> > > >
> > > > Gary
> > > >
> > > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> > ralph.go...@dslextreme.com>
> > > > wrote:
> > > >
> > > > > Can you please clarify, “If we had some way to know an event is a
> > > business
> > > > > event we wouldn’t need level”?  I do not understand how you can code
> > > > > logger.log(BUSINESS, msg)  but you cannot code logger.info(BUSINESS,
> > > msg).
> > > > >
> > > > > Ralph
> > > > >
> > > > > > On Sep 8, 2015, at 6:09 PM, Nicholas Duane  wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I looked over that stackoverflow post and I'm still not seeing a
> > good
> > > > > match as a way for us to log our business events.
> > > > > >
> > > > > > A business event I guess is an event which extends whatever schema
> > we
> > > > > come up with for a business event.  While an instance of this schema
> > > could
> > > > > be logged at any level, that really doesn't make sense in our
> > scenario,
> > > > > regardless of whether some marker was supplied.  If we had some way
> > to
> > > know
> > > > > an event is a business event we wouldn't need level.  We could of
> > > course
> > > > > add some property to our schema which indicates the 'category' of the
> > > > > event, 'business' being one such category.  Instead we were thinking
> > we
> > > > > could just use level to indicate that an event is a business event.
> > > > > >
> > > > > > As I mentioned, we're looking to capture 'trace' level events to
> > one
> > > > > store, 'info' - 'fatal' 

Re: approach for defining loggers

[Ralph Goers]

> On Sep 11, 2015, at 3:50 PM, Gary Gregory  wrote:
> 
> 
> This updated text I hope will help:
> 
> "No new loggers needed, just an additional parameter to your log call,
> regardless of the level API used.
> 
> Now, I can configure Log4j to log only events that contain the marker DOOR
> (if that level is enabled).”

This isn’t necessarily true.  If you have a global filter that accepts the 
event then the log level of the appropriate logger will not be checked. 
However, other filters on the AppenderRef and Appenders will still be checked.

Ralph

Re: approach for defining loggers

[Gary Gregory]

On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers 
wrote:

>
> > On Sep 11, 2015, at 3:50 PM, Gary Gregory 
> wrote:
> >
> >
> > This updated text I hope will help:
> >
> > "No new loggers needed, just an additional parameter to your log call,
> > regardless of the level API used.
> >
> > Now, I can configure Log4j to log only events that contain the marker
> DOOR
> > (if that level is enabled).”
>
> This isn’t necessarily true.  If you have a global filter that accepts the
> event then the log level of the appropriate logger will not be checked.
> However, other filters on the AppenderRef and Appenders will still be
> checked.
>

Hm, OK, but I am not sure I want to make that part of the article more
complicated. I could say "if that level is enabled and a global filter did
not accepts the event".

Gary

>
> Ralph
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

RE: approach for defining loggers

[Nicholas Duane]

I am a bit confused now.  Previously someone said that if we used markers the 
level used in the log statement would be irrelevant.  However, based on this 
thread it looks like that's not the case.  Can someone give a definitive answer 
on what determines whether an event makes it to an appender?

Thanks,
Nick

> Date: Fri, 11 Sep 2015 16:46:14 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers 
> wrote:
> 
> >
> > > On Sep 11, 2015, at 3:50 PM, Gary Gregory 
> > wrote:
> > >
> > >
> > > This updated text I hope will help:
> > >
> > > "No new loggers needed, just an additional parameter to your log call,
> > > regardless of the level API used.
> > >
> > > Now, I can configure Log4j to log only events that contain the marker
> > DOOR
> > > (if that level is enabled).”
> >
> > This isn’t necessarily true.  If you have a global filter that accepts the
> > event then the log level of the appropriate logger will not be checked.
> > However, other filters on the AppenderRef and Appenders will still be
> > checked.
> >
> 
> Hm, OK, but I am not sure I want to make that part of the article more
> complicated. I could say "if that level is enabled and a global filter did
> not accepts the event".
> 
> Gary
> 
> >
> > Ralph
> >
> >
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory