commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <sgarl...@users.sourceforge.net>
Subject Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Date Tue, 28 Dec 2004 00:40:16 GMT
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


Mime
View raw message