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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]