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

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



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


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