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)
Subject: Re: [general] logging
From: Simon Kitching <simon@ecnetwork.co.nz>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <Pine.LNX.4.44.0408302117050.14226-100000@orinoco.flamefew.net>
References: <Pine.LNX.4.44.0408302117050.14226-100000@orinoco.flamefew.net>
Content-Type: text/plain
Message-Id: <1093918205.25613.37.camel@pcsimon>
Mime-Version: 1.0
Date: Tue, 31 Aug 2004 14:10:05 +1200
Content-Transfer-Encoding: 7bit

On Tue, 2004-08-31 at 13:27, Henri Yandell wrote:
> On Thu, 26 Aug 2004, Craig McClanahan wrote:
> 
> > You are asking two separate but related quesitons here, so they should
> > be addressed separately.
> >
> > (1) Should libraries depend on *any* logging library?
> >
> > It seems obvious to me that libraries would benefit from having
> > logging embedded.  It's not just for the library developers to debug;
> > it is also for the library *user*.  Digester is actually a classic
> > example of this use case ... debugging your matching rules is MUCH
> > easier when you can turn on trace level debugging to see which rules
> > are actually getting matched, and what order the rules are being fired
> > in.
> 
> Just to bring up another thought on this question, what happens in other
> languages/techs?
> 
> Does glibc contain lots of debug statements (I assume to syslog?). Does
> Swing contain lots of debug statements? Do libraries contain their own
> plugins to the -w flag in Perl? (Might do for all I know).

Well, the sshd application contains logs of debug statements to syslog,
and these can be absolutely vital in tracking down login problems.

The DB2 database has diagnostic logs that can be tuned to generate
various amounts of data. Actually, the diagnostic output is next to
useless, but the principle is there.

I would guess that J2EE app servers have diagnostic output available
(others may be able to give details).

> 
> I'll happily agree that debugging statements in code is very useful
> (despite the arguments of the IDE debuggers), but I'm unconvinced that
> released stable binaries should contain the debugging etc. It seems
> unlikely to be of a lot of use to direct users, and definitely of less use
> for third-hand users (think developers of Struts trying to navigate
> through Digester debugging statements).

I vigorously disagree with this statement. 

The ability to turn on logging in an application which is deployed in
production is extremely important. You can't always duplicate problems
in test enviroments (particularly when the problem is occurring at a
customer site). And you certainly can't run code in a production
environment under debugger control. And going through the paperwork to
deploy specially-compiled versions of apps with debugging enabled can be
a *major* hassle. Of course enabling logging does have a performance
impact (which is why it is important that the logging system have the
ability to carefully select subsets of messages relevant to the
problem), but it is much easier to get agreement to tweak such settings
than to deploy new executables. If the logging can be reconfigured
without restarting the application concerned, that is even better.

As a developer of software deployed in large commercial sites, I *love*
the ability to leave logging statements in production code, and
enable/disable them as required.

In your example of Struts users, yes they *can* understand what the
digester log statements mean. And if they can't, they can post such logs
to the appropriate email list and get advice on what the problem is.


When library functions are so simple that their return codes or
exception objects *completely* describe the problem which occured, then
logging within the library may not be necessary because the calling code
has all the necessary info to generate good error messages to the user
(potentially via logging). This description may well apply to the
majority of glibc functions. And may well apply to most of o.a.c.lang or
o.a.c.collections. But this description does *not* fit well with many
other commons libraries, digester being a prime example. 

Digester has loads of "state", so the true cause of a problem may be
related to a method call well-removed from the point at which the error
occurred. And logging is a very good way to track these issues down. I
expect that "configuration" has similar issues, and maybe other commons
libraries.

Regards,

Simon


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