DO NOT REPLY [Bug 36927] - [logging] Disabling of TCCL

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36927>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36927





------- Additional Comments From skitching@apache.org  2006-01-15 12:24 -------
I have a proposal. I've implemented what's described below, and have unit tests
mostly working for it so it's ready to go pretty soon if there are no objections.

== part 1 ==

When loading commons-logging.properties files, currently the first one found in
the class is used. 

Instead, I propose that commons-logging.properties files can contain a
"priority=n" . Files without an entry default to priority=0. The priority value
is a floating-point number. When loading properties files, every file in the
classpath is checked, and the one with the highest priority is used.

This allows webapps to provide a config file, but for the container
administrator to override these by placing a file of higher priority in the
shared path. A webapp can then override *that* if it wants by defining an even
higher priority.

This isn't a major performance hit as it is done only once per distinct TCCL (ie
per webapp in a container).

Priority numbers aren't perfect as they do require some "coordination" between
the different levels. However I don't think there's anything better in this case.

== part 2 ==

Allow commons-logging.properties files to contain a key
  use_tccl=false
If this is present, then *for the current TCCL* all loading is done via the
classloader that loaded the LogFactory class. 


== effect ==

Together, these features allow the following:
(a) 
A single webapp can disable tccl logging for itself by having a
commons-logging.properties file with use_tccl=false.

(b)
A container administrator can disable TCCL-based logging for all webapps by
simply placing a commons-logging.properties file in a shared classpath location
with priority=10 and use_tccl=false. This will override any settings in any
webapp. However a specific webapp can override this again with a higher-priority
value for its config file.


At a technical level, there will still be a LogFactoryImpl for each distinct
TCCL, keyed by the TCCL. However a call to LogFactory.getLog made when the
current tccl matches one associated with a "use_tccl=false" configuration will
always return a concrete Log class that is loaded via the same classloader that
loaded the LogFactory class.


Opinions?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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