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: commons-logging auto-detection WAS: [logging] Enterprise    
    Common Logging... dare we say 2.0?
Date: Mon, 27 Dec 2004 19:40:16 -0500
Lines: 69
Message-ID: <cqqa1j$5pt$1@sea.gmane.org>
References: <6.0.3.0.0.20041226171859.03e7c4f0@mail.qos.ch>
 <20041227021515.399A91EC073@mail.qos.ch>
 <6.0.3.0.0.20041227124408.03bc2c70@mail.qos.ch> <cqpnlb$5ue$1@sea.gmane.org>
 <6.0.3.0.0.20041228000728.03a62d18@mail.qos.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
In-Reply-To: <6.0.3.0.0.20041228000728.03a62d18@mail.qos.ch>
Sender: news <news@sea.gmane.org>

I think often JCL will be used as you describe, but not always.

For example, let's say I am developing a component that monitors 
database activity and monitors usage statistics (this is a hypothetical 
example).  The main purpose of this component is to log messages to be 
processed later by a human.  I use JCL and put a 
commons-logging.properties in my org.dbmonitor package that says "use 
Log4J and display INFO and higher messages".

This component may be deployed in many different environments.  Here are 
two examples:
1) Standalone on a server.  In this case, the default settings specified 
at the component level should be used.
2) As a component of another application.  In this case, the overall 
application specifies logging properties that overwrite those in the 
component.  To do this, the application specifies a 
commons-logging.properties in the default package, which overwrites the 
properties specified at the component level.  In this example, the 
application chooses it only wants WARN and higher messages and that it 
wants the messages rendered with JDK 1.4 logging.

My point is that one overall configuration of logging for the entire JVM 
may be too restrictive.  I think we could benefit from multiple JCL 
configurations, each targeted at different parts of a system.

Matt

Ceki G�lc� wrote:
> 
> Matt,
> 
> JCL exists mainly for the purpose of libraries wishing to *integrate*
> with the logging API chosen by the user by deferring the selection of
> the logging impl to runtime. The author of library "net.sf.morph"
> probably does *not* wish to impose any logging related property on the
> end-user. Consequently, it does not make sense to have package
> specific properties at the JCL level. Would you agree?
> 
> 
> At 08:26 PM 12/27/2004, Matt Sgarlata wrote:
> 
>> Couldn't this be refined even further by incorporating a change to JCL 
>> I proposed earlier?  Here's a copy of my original post:
>>
>> 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 
>>
> 
> 


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