commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Thu, 16 Dec 2004 17:47:46 GMT

--- Richard Sitze <rsitze@us.ibm.com> wrote:

> Simon Kitching <s_kitching@paradise.net.nz> wrote on 12/15/2004 10:18:44
> 
> PM:
> 
> > On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
> > > Simon Kitching wrote:
> > > > I think this demonstrates a major issue.
> > > > 
> > > > When using logging in an "enterprise" situation, the logging can
> be
> > > > considered a critical part of the application. If you have 
> heavy-duty
> > > > monitoring systems watching for alerts from the software, and have
> > > > sysadmins on call 24x7 to deal with issues, then for an
> application 
> to
> > > > fail to locate the correct logging libs or config files is a 
> *failure*
> > > > of the app. You don't want an app to start up, but then not be
> able 
> to
> > > > generate alerts if problems occur.
> > > > 
> > > > But when using logging in other situations, logging is *not* a 
> critical
> > > > part, and should not cause an application to fail to start.
> > > > 
> > > > The latter is the focus of commons-logging at the moment. And
> > > > unfortunately as commons-logging has no *mandatory* configuration,
> 
> it is
> > > > not possible to add a "fail-on-no-config" option!
> > > > 
> > > > So perhaps we could build two separate jars from mostly-common 
> source
> > > > code? Deploying the traditional commons-logging jar would do the
> "be
> > > > quiet on no config", while the "enterprise" commons-logging jar 
> would do
> > > > something like "write message to STDERR then throw a runtime 
> exception
> > > > on no config"?
> > > 
> > > Why not just introduce a boolean parameter that says whether or not
> an 
> 
> > > inability to log is a failure?  e.g.
> > > 
> > > Log log = LogFactory.getLog(MyClass.class, true);
> > 
> > It's not "inability to log" as such. It's whether finding no specific
> > config info or underlying log implementation and therefore falling
> back
> > to using java.util.logging (java>=1.4) or
> > org.apache.commons.logging.SimpleLog (java<1.4) is allowed or not.
> > 
> > In many cases, what you *want* an app to do if it can't find any
> > specific logging config is simply to output ERROR and FATAL messages
> to
> > stderr. This is what commons-logging will currently do if its
> > "discovery" process finds nothing.
> > 
> > I guess commons-logging *could* use a parameter such as you suggest to
> > indicate "explicit configuration of logging is mandatory". This would
> > presumably mean detecting whether commons-logging.properties or the
> > corresponding system properties have defined an explicit log
> > implementation and config file for that implementation.
> > 
> > I'm not sure, however, if the decision on whether logging is mandatory
> > or not should be a compile-time one. It seems to me to be more like
> > something the application *deployer* should choose. That then leads us
> > to a circular reference: how do we know whether configuration is
> > mandatory or not, if we can't find any configuration?
> 
> The current proposal is:
> 
> - configuration is always manditory.

Doesn't mandatory configuration relieve us from needing to split
commons-logging.jar into several pieces?  I like the fact that I don't
have to manage multiple commons-logging jar files and will be rather
dissapointed if that is required in the future.  I wouldn't mind having a
simple properties file or a system property like
-Dorg.apache.commons.logging.impl=log4j that tells commons-logging to use
log4j.

David

> 
> - ambiguous [multiple] configurations located by a particular
> ClassLoader 
> in the hierarchy requires an "error" to be logged [where is a reasonable
> 
> question to ask].  How we determine which configs belong to which 
> ClassLoaders is described in the original proposal.
> 
> - in a "core" JCL jar, a configuration *must not* be packaged with JCL.
> 
> - in a "helper" JCL jar, a configuration *must* be packaged, along with 
> *one* JCL logger wrapper class.
> 
> - multiple "helper" JCL jar files, one per logging impl wrapper we 
> support.  Pick the logger impl you want, grab the corresponding "helper"
> 
> JCL jar file, and drop it into your application.
> 
> 
> > 
> > Regards,
> > 
> > Simon
> > 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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


Mime
View raw message