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: domain of rsitze@us.ibm.com designates
 32.97.110.132 as permitted sender)
In-Reply-To: <6.0.3.0.0.20050121202718.02e1e160@mail.qos.ch>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
MIME-Version: 1.0
Subject: Re: [logging] API - methods for logging entry and exit events
From: Richard Sitze <rsitze@us.ibm.com>
Message-ID: 
 <OFB984C857.97A6FFA9-ON86256F90.006D511E-86256F90.006E941F@us.ibm.com>
Date: Fri, 21 Jan 2005 14:07:49 -0600
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Ceki G=FClc=FC <ceki@qos.ch> wrote on 01/21/2005 01:45:46 PM:

>=20
> Logging too much can be as bad as the absence of logging.
>=20
> Cluttering the log output with entry and exit events will increase the
> amount of noise and negatively impact the usefulness of the
> logs. Consequenly, logging enter and exit events amount to bad practice.
>=20
> For a deployed system, which one would assume has undergone some
> testing, no one, and I mean no one, will care about method entry and
> exit. A developer may have use for entry and exit methods during
> development but such statements should be removed well before the
> application is deployed.

Well Ceki, there are many views out there.  I don't only disagree based on =

opinion of best-practice, I disagree from experience with Enterprise=20
[large scale 24/7 business] customers, and person experience with=20
developing and maintaining applications running in these spaces.

The purpose of logging is to capture enough state of a system, so that=20
when you identify *where* the error occurs in the logs, you have=20
information that can help you identify the cause of the error.=20
Class/method 'boundries' are convenient for many reasons, not least of=20
which is that in a well designed [dare I say OO?] modularized software=20
component the methods are [typically] relatively short and "functionally=20
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=20
system in the same way that an entry log entry [eeks] would.  Entry/exit=20
help you identify the state of the system at the time a fault occurs, and=20
in many cases can identify the fault itself.

Likewise, errors can be caused by earlier events....the entry/exit flow=20
information can help identify the factors related to such.. again based on =

conveniant boundries in the code.

I do agree that with some serious planning [thought], and effort that=20
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=20
hindsight in many components.  We don't always *have* the luxury of=20
hindsight.  In these cases, the more information logged the better.

entry/exit logging is a best-practice that is *easily* understood by=20
developers, it provides a minimal set of information that can offer a=20
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=20
Logging' services ;-).

>=20
> --=20
> Ceki G=FClc=FC
>=20
>    The complete log4j manual: http://www.qos.ch/log4j/
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


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