AW: adding lower level debug statements for context-information

[Stadelmann Josef <jo...@axa-winterthur.ch>]

I think what you should do is

a) configure the logger of modules which show a tendency to fail to log at the debugger level 

b) while all other loggers shall remain working at the warning or error level 

Loggers are organized in a tree hierarchies - knowing your tree is all. With that caller graph know-how you could pass the logger level as an optional argument to your called objects-method which can then adjust their loggers to work at the demand level. You can make this passed arguments optional, and that would allow the loggers of all called object to selectively remain at the warning level or adjust itself to the required level asked for by the caller when the optional argument in the method call is set.

You could also establish a java system property and make your loggers dynamically set it to the required level if not already there and make loggers adjust itself to this lower level or remain at their even lower level up on return. 

i.e. caller adjusts to warning, logger is at debug, logger has no need to do anything because configuration demands this logger to log at debug level
i.e. caller adjusts to debug level, logger is at warning level, logger stacks its current level and adjust for the runtime of the method called to log at debug level. Prior to return via normal return or exception handling, the logger adjust itself to its stacked level prior to return to caller.

I think the combination of configurability of various loggers, with additivity set to false on demand by code or configuration for any particular loggers plus the possibility to adjust logger levels on demand in code gives you sufficient control over what you want, given you know what you want and do not loos the control over your potentially iteratively called object methods.


You can also think about writing your own a logger or appender which sends its logging events to a bigger in-memory-ring-buffer. Instead of doing IO, the logger hierarchies will log into this memory-ring-buffer overwriting too old events. Up on a trigger or event or exception this ring-buffer is then sent to a real logger for output into a file or a consol or to CHAINSAW clients prior to clearing it. The size of the ring-buffer shall be adjustable.

I personally feel it is a matter of architecture, architecture of what you want in this situation. Using CHAINSAW shows you what loggers you have and allows you to fine configure certain loggers and let other work at ERROR or Warning level, be it by code or configuration properties or both.

Josef

 





-----Ursprüngliche Nachricht-----
Von: Carlos Freund [mailto:karlsfriend@yahoo.de] 
Gesendet: Mittwoch, 25. August 2010 16:01
An: Log4J Users List
Betreff: Re: adding lower level debug statements for context-information



I agree the example doesn't really bring the point across. In the real world there would be much more debug statements and the LOG.error call would be much higher in the stack than the place where the error occurs. 

Are more typical example might simply be a NullPointerException that is logged in some outer try-catch-block. 
You know the line, where it happened, but you don't know how the variable got to be null in the first place. 

> Maybe your example is too simplistic
> but,  I do not see why you
> could not do this for your error log statement:
> 
>     LOG.error("Could not calculate average age
> for persons: " +persons);
> 
> -Ryan
> 
> >
> > On 25 August 2010 14:08, Carlos Freund <ka...@yahoo.de>
> wrote:
> >
> > > Hello,
> > >
> > > I've been using log4j for some time now and it's
> working really fine.
> > > However i have trouble with setting the
> log-levels right.
> > >
> > > I am working on a server that gets quite some
> load.
> > > At first I set the log-level to debug. This was
> very convenient for, well,
> > > debugging. When the server got heavier load this
> got impractical because the
> > > log files would inflate and IO caused by logging
> became noticeable.
> > >
> > > So i set the log level to warn. That solved those
> problems. But now when
> > > the occasional error occurs it has become much
> harder to figure out why.
> > > Before I had the debug statements from which I
> could tell, what was wrong.
> > > Now i just have a Exception and a stacktrace,
> which sometimes just isn't
> > > enough information.
> > >
> > >
> > > So what I'd really like would be a compromise of
> these two options. I was
> > > thinking about a possibility to configure a
> logger so it would add the last
> > > X log
> > > messages of lower levels whenever an log of the
> "regular" level would be
> > > written.
> > >
> > > A Simple example:
> > >
> > > public double getAvgAge(List<Person>
> persons){
> > >  LOG.debug("Calulating average age for
> persons: "+persons);
> > >  try{
> > >    int total_age =
> getTotalAge(persons);
> > >    double avg_age = total_age /
> persons.size();
> > >    return avg_age;
> > >  } catch (Exception e ){
> > >    LOG.error("Could not calculate
> average age");
> > >    throw e;
> > >  }
> > > }
> > >
> > >
> > >  I'd like to be able to set up log4j so that
> it doesn't log anyting if the
> > > code works(calls no LOG.error). But when it does
> call LOG.error i'd like to
> > > also see the previous debug statements in my log
> so I can figure out why my
> > > code failed.
> > >
> > > So i would read something like this in my log:
> > > DEBUG AverageAgeCalculator: Calulating average
> age for persons: [ ]
> > > ERROR AverageAgeCalculator: DivideByZeroError
> > > ....stacktrace....
> > >
> > > But no unnecessary statements like:
> > > DEBUG AverageAgeCalculator: Calulating average
> age for persons: [Mary,
> > > Peter ]
> > > DEBUG AverageAgeCalculator: Calulating average
> age for persons: [Carlos,
> > > Hans, Klaus]
> > >
> > >
> > > I happen to have some free time on my hands so
> i'd like to try to code this
> > > myself.
> > > But before i start thinking about implementation,
> I would like to know some
> > > things.
> > >
> > > Does something like this already exist?
> > > Do you think this would be useful?
> > >
> > > Greetings, Carlos Freund
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org