commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Thu, 16 Dec 2004 16:51:32 GMT
Just for the record, the primary issue is NOT inability to locate a 
logger.  It's not finding the "expected" logger [from the developer/users 
perspective], and silently falling back to an "alternate" logger.


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

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?
> 
> Regards,
> 
> Simon
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


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