Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of jak-commons-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: commons-dev@jakarta.apache.org
From: Matt Sgarlata <sgarlatm@users.sourceforge.net>
Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date: Thu, 16 Dec 2004 00:04:57 -0500
Lines: 88
Message-ID: <cpr51r$gd2$1@sea.gmane.org>
References: 
 <OF9C38DE40.A14E753F-ON86256F6B.007448D8-86256F6B.00754B6E@us.ibm.com>
 <1103156615.3684.23.camel@blackbox> <cpqmb8$mkc$1@sea.gmane.org>
 <1103170723.3684.44.camel@blackbox>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
In-Reply-To: <1103170723.3684.44.camel@blackbox>
Sender: news <news@sea.gmane.org>

Response below...

Simon Kitching wrote:
> 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?

Ah-hah, I see what you're getting at.

I have an idea... All logging implementations for Java configure logging 
by package, right?  What if we allow component developers to include 
their own commons-logging.properties that's not at the root of the 
source tree?  For example, if Morph suddenly decided it was very 
important to have certain messages logged, I just drop a 
commons-logging.properties in net.sf.morph that specifies the logging 
settings for net.sf.morph and all subpackages (e.g. which log factory to 
use, whether my messages *must* be heard, etc).  If JCL detects such a 
file it ensure the component that the logging it specifies is happening. 
  If an application developer, assembler or deployer decides later that 
Morph really isn't as important as I'd like, then they just delete the 
commons-logging.properties or put their own version in the 
WEB-INF/classes directory.  (Forgive me if this is a great show of my 
ignorance of classloading, but I think this is at least how things work 
for Tomcat).

Searching for a file like this on the classpath would certainly have 
performance implications.  However, search cost is incurred only on 
startup and there is precedent (see below), so it can't be too bad. 
It's certainly worth a try.

http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html

> Regards,
> 
> Simon

Matt


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