commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Date Mon, 27 Dec 2004 23:13:56 GMT

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

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/



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