commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject RE: Problems with commons-logging
Date Mon, 04 Feb 2002 21:44:19 GMT
I've been thinking about this. The situation you're outlining goes something
like this at the code level:

if (someHorribleCondition) {
  log.error("Bad Things Happened Here");
  //Now what?
}

If the //Now what? doesn't include a thrown exception, but it's severe
enough to cause the application using the compenent to fail, the component
has a real problem, not just a logging issue.

Now, maybe the debug level of logging might provide enough insight to debug
the problem, but that's not a good default for unconfigured logging.


> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: Sunday, February 03, 2002 3:05 AM
> To: Jakarta Commons Developers List
> Subject: Re: Problems with commons-logging
> 
> 
> From: "Steve Downey" <steve.downey@netfolio.com>
> > The configuration should be done with the logging package 
> API. A component
> > is not going to do configuration, the application, or the 
> administrator,
> is
> > going to. The components need a uniform way of accessing the logging
> system
> > that the application is using.
> 
> Agreed.
> 
> > Incidentally, this implies to me that if no logging system 
> is configured,
> > then components should not log. It should be a no-op. Not 
> even print to
> > stderr. [god forbid stdout]
> 
> This I'm not sure of.
> 
> Imagine the use case of end user trying to run some application with a
> component using commons-logging - but their classpath doesn't 
> have a logging
> package on it by accident (its *very* common to mess up 
> classpaths or miss
> dependencies, JJAR where are you ;-). Lo and behold the 
> application runs,
> terminates due to some failure of some kind but the user 
> can't see what the
> issue is. No output is produced whatsoever. Or maybe worse, 
> all the commons
> components errors are hidden but application developers 
> errors come out
> sending them on a wild goose chase. They have to guess that 
> the issue is
> that a logging package is required before they see the real 
> reason for the
> application terminating.
> 
> Just to fix this common case I'd prefer the default to be 
> SimpleLog with
> ERROR level logging to System.err. (Maybe with a small 
> warning on the first
> line that no logging package is configured).
> 
> If a user really wants to disable all logging (which is quite 
> rare IMHO - if
> something goes wrong we usually wanna see it somewhere) they 
> can with the
> system properties in SimpleLog.
> 
> James
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> 

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


Mime
View raw message