In ContextJNDISelector removed the code that performs a lookup on log4j.xml or log4j.properties files (for non-default repositories.) Code checked in.
At 02:11 AM 11/29/2004, Jacob Kjome wrote:
I understand what you are trying to say. However, I think the premise is false. To assume that using the thread context classloader will avoid loading resources from, say..., Tomcat's common/classes is just incorrect. You are right that preference will be given to the resource in WEB-INF/classes. However, if that is not found, normal Java2 classloading behavior resumes and a log4j.xml file in common/classes would, in fact, be found and utilized. I can't imagine what your proposed Loader.getResourceByTCLOnly() would accomplish and I'm not sure it is a solvable problem. The only solution I can see is to perform initialization on non-default repositories if, and only if, the configuration was provided via the "log4j/configuration-resource" JNDI entry and not fall back to loading off the classloader. In this case, applications would need to perform manual configuration. An alternative to this is to keep the current behavior or falling back to the classloader to find the config file and tell users that actually want to perform manual configuration (for whatever reason) to put a minimal config file in WEB-INF/classes to pacify autoconfiguration and then perform the manual configuration that they so desire.
Thoughts?
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
