Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <6.0.3.0.0.20050122152806.03826520@mail.qos.ch>
Date: Mon, 24 Jan 2005 18:06:21 +0100
To: commons-dev@jakarta.apache.org
From: Ceki =?iso-8859-1?Q?G=FClc=FC?= <ceki@qos.ch>
Subject: Re: [logging] API - methods for logging entry and exit events
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Richard Sitze wrote on 2005-01-21 20:07:49:

 >The purpose of logging is to capture enough state of a system, so that
 >when you identify *where* the error occurs in the logs, you have
 >information that can help you identify the cause of the error.
 >Class/method 'boundries' are convenient for many reasons, not least of
 >which is that in a well designed [dare I say OO?] modularized software
 >component the methods are [typically] relatively short and "functionally
 >defined" by their parameters.  Stack traces for exceptions [if you HAVE an
 >exception] can identify a method, but don't capture the state of the
 >system in the same way that an entry log entry [eeks] would.  Entry/exit
 >help you identify the state of the system at the time a fault occurs, and
 >in many cases can identify the fault itself.

In other words, you are advocating the use of logging as a sort of
persistent debugger. Clearly, a debugger can provide a perfectly
detailed view of the system, down to the register level. However, no
one usually cares about that much detail. Not only is that level of
detail distracting, it will noticeably slow down the application and
hog megabytes of disk space. Is indiscriminate logging IBM's secret
justification for ever bigger and faster machines?

 >Likewise, errors can be caused by earlier events....the entry/exit flow
 >information can help identify the factors related to such.. again based on
 >conveniant boundries in the code.

Theoretically speaking, there is no denying that as the quantity of
information about the system increases, so does the probability of
finding the cause of a given error. But where do you stop?

 >I do agree that with some serious planning [thought], and effort that
 >there may be more helpful bits of information to log in some cases, but if
 >experience shows anything it is that these are typically identified from
 >hindsight in many components.  We don't always *have* the luxury of
 >hindsight.  In these cases, the more information logged the better.

Let me present this from a different angle.

Logging is about fixing the next run, not the current one. The current
one failed, rememberer? So, in some sense, you always have the luxury
of hindsight, almost by construction.

You can rely on log files with tons and tons of noise, or you can look
at less detailed logs but which still provide a view of the big
picture. Armed with the big picture you can try to reproduce the
problem on your side. Once you are able to reproduce the error, you can
fix it.

 >entry/exit logging is a best-practice that is *easily* understood by
 >developers, it provides a minimal set of information that can offer a
 >significant improvement over speriodic logging within the code.
 >
 >Now... if you feel that such methods are not appropriate for the 'general'
 >case... while I disagree, I won't argue *too* strongly.. but I would point
 >out that we have requested these API's under the guise of 'Enterprise
 >Logging' services ;-).

Now that you mention it, one the reasons which got me working on log4j
and its filtering mechanisms, was the thousands of lines of garbage
generated by the logs of an IBM product, which will go unnamed
here. You seem approach logging from a different perspective
altogether:

   Dump as much information as you can, worry about sorting through
   the mess later.

Is that a fair description?


--=20
Ceki G=FClc=FC

   The complete log4j manual: http://www.qos.ch/log4j/


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