commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: [general] logging
Date Tue, 31 Aug 2004 03:18:00 GMT
On Tue, 31 Aug 2004 14:10:05 +1200, Simon Kitching
<> wrote:
> 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).

They do, and I couldn't live without it. It's absolutely crucial to
understanding how things are (not) working when you're trying to
diagnose a problem. When you have a large complex app running on a
full-blown app server, being restricted to only your own debugging
output would be worse than working in the dark.

> > 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.

+1 to all of that.

> 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.

This is, in fact, one of the precise cases I had in mind when I
commented on logging being essential in an earlier message. It's
exactly because Digester has good logging output that people are able
to diagnose problems with their Struts config files.

> 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.

Again, +1 from me.

Martin Cooper

> Regards,
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message