logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Dorrat <simon.dor...@gsjbw.com>
Subject Re: [VOTE] Adding the TRACE level
Date Mon, 15 Mar 2004 00:34:15 GMT

Reading the bylaws, I noticed that it encourages general developers and
users to vote, even though the votes are unofficial.  I have only just
recently joined the mailing list and would like to add my two cents worth.
I have been using home grown logging for 12 years in major infrastructure
apps and feel strongly about this.

*	I think that the more flexibility there is in logging levels the
more likely logging will be accepted by sceptics in an organisation, as high
and/or medium level non-error logging can be left on in production without
enourmous performance and space impact.   In certain applications, a need
may often exist to increase the level of logging further, not for developer
information but to get details of the flow of a request/mesage/order etc
through the business logic of an application.  When this happens, not having
to sift through reams of really low level trace statements is a godsend and
means a wider range of people can perform this diagnosis task. 

Intelligent use of a good logging framework cuts down time taken to diagnose
runtime issues of complex systems enormously, and helps people other than
the authors get their heads around the apps quickly.  Anything that helps
this process, (like a bigger hierarchy of log statements) should be

*	I dont know anything about the new domains that Ceki talked about so
I cant comment on whether these will negate the need.

*	To give an idea of how I think the levels should be used, This is
how I have extended the Level class.  I have added the following levels:

	CONFIG: Configuration information- system/app specific properties,
details of connections made (CORBA domains, databases, JMS)
	PERF: Performance metrics- our wrapper prepends "perf." to the
category to allow any performance stats to be handled via a specific
	INFO_HIGH:High level logging, usually one line per request processed
successfully ("Order #M156299 for Buy 10000 NCP Client XXXXXX processed
	INFO_MED:Medium level logging, 5-15 lines per request - Will show
major flow through business logic
	INFO_LOW:Low level, will show detailed path through code, alot of
"About to do ...." to allow pinpoint problems, showing value of flags,
counters etc.

	INFO_MED maps to the standard INFO level.  DEBUG is still used as
well for dumping entire messages etc, but is not crucial.  

	For many years the C version of our logging framework used an open
ended numbered system, and 3 levels of non-error log was sufficient.  Only
rarely was level 4 used, but since I was adding a number of other levels to
log4j I added 3 info levels and left DEBUG.  If TRACE is added though, I can
possibly map INFO HIGH/MED/LOW to  INFO/DEBUG/TRACE via our wrapper and be
able to reduce our proprietry extensions.

*	Extending the level is OK, but means I had to extend LogFactor5 as
well to support it, and means we dont have the option of using apache
commons-logging, which some products (weblogic?) may require.  Since I have
wrapped everything, the need to use the generic logger.log call has no

*	Elias, correct use of categories doesnt help - the issues is
horizontal (app-wide) filtering not vertical (package hierarchy) filtering.

I have constantly had to battle others in organisations I have worked for to
get acceptance for a detailed logging strategy.  This includes other
developers as well as support and h/w & OS administrators.  Having useful
logging with minimal standard impact, that could easily be extended at
runtime to the right level to allow people to get the information they
needed, has allowed me to win most of these people over and ensure that
permanent logging statements are left in code.  I feel having the extra
level will help others in the same way.


Goldman Sachs JBWere
Disclosure of Interest
NCP:  Goldman Sachs JBWere and/or its affiliates have received during the past 12 months compensation
for financial and advisory services from the company, its parent, or its wholly owned or majority
owned subsidiary.
NCP:  Goldman Sachs JBWere and/or its affiliates expect to receive or intend to seek compensation
for financial and advisory services in the next 3 months from the company, its parent, or
its wholly owned or majority owned subsidiary.
NCP:  Goldman Sachs JBWere and/or its affiliates make a market in the securities of the company.
NCP:  Goldman Sachs JBWere does and seeks to do business with companies covered in its research
reports.  As a result, investors should be aware that Goldman Sachs JBWere may have a conflict
of interest that could affect the objectivity of this report.  Investors should consider this
report as only a single factor in making their investment decision.
NCP:  Goldman Sachs and Goldman Sachs JBWere each have research coverage of the company the
subject of this report. Any views, investment opinions or recommendations relating to the
subject company published by Goldman Sachs JBWere are independently developed and may differ
from those published by Goldman Sachs.


Goldman Sachs JBWere Pty Ltd and its related entities distributing this document and each
of their respective directors, officers and agents ("the Goldman Sachs JBWere Group") believe
that the information contained in this document is correct and that any estimates, opinions,
conclusions or recommendations contained in this document are reasonably held or made as at
the time of compilation.  However, no warranty is made as to the accuracy or reliability of
any estimates, opinions, conclusions, recommendations (which may change without notice) or
other information contained in this document and, to the maximum extent permitted by law,
the Goldman Sachs JBWere Group disclaims all liability and responsibility for any direct or
indirect loss or damage which may be suffered by any recipient through relying on anything
contained or omitted from this document.

Goldman Sachs JBWere does not represent or warrant the attached files are free from computer
viruses or other defects.  The attached files are provided, and may only be used, on the basis
that the user assumes all responsibility for any loss, damage or consequence resulting directly
or indirectly from use.

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

View raw message