Dan,
Are you sure? I have personally tested this feature on Linux and Windows using JVMs
from Sun and IBM. Regards, Ceki
At 09:19 28.05.2001 -0400, you wrote:
>Ok, in v0.9.1, the Loader class was not used for loading the
>log4j.proeprties file. It was loaded via the following static block in
>the Category class:
> /** Search for the properties file log4j.properties in the CLASSPATH.
>*/
> static {
> String override = null;
> try {
> override=System.getProperty(DEFAULT_INIT_OVERRIDE_KEY, override);
> } catch(SecurityException e) {
> LogLog.debug("Could not read system property \""+
> DEFAULT_INIT_OVERRIDE_KEY +"\".", e);
> }
> if(override == null || "false".equalsIgnoreCase(override)) {
> ClassLoader loader = org.log4j.Category.class.getClassLoader();
> if(loader == null) {
> LogLog.debug(
> "Could not find class loader. Skipping default
>initialization.");
> } else {
> // We do not use the method getResources but use getResource
> // instead in order to be compatible with JDK 1.1.x.
> URL url = loader.getResource(DEFAULT_PROPERTIES_FILE);
> if(url != null) {
> PropertyConfigurator.configure(url);
> }
> }
> }
> }
>
>Now, in v1.1.1, the log4j Loader class loads the log4j.properties file
>via the ClassLoader object. When it gets the ClassLoader object, it
>does so with a passed in reference to Object.class. As mentioned in my
>prior email, it does not appear that the ClassLoader from a different
>class can be retrieved (via a call to getClassLoader() ) from another
>class' static block. This seems to be the case with SUNs and IBMs JVMs.
>
>The end result is that log4j no longer picks up a log4j.properties file
>that is located in the root of any classpath entry.
>
>Dan
>
>-----Original Message-----
>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, May 26, 2001 2:26 AM
>To: LOG4J Developers Mailing List
>Subject: Re: Loader class
>
>
>
>Dan,
>
>I have read and re-read your mail. I still don't understand it. Regards,
>Ceki
>
>At 14:43 22.05.2001 -0400, you wrote:
>>In the 0.9.1 version of log4j, the ClassLoader was retrieved via:
>> ClassLoader loader = org.log4j.Category.class.getClassLoader();
>>now it is retrieved like this:
>> ClassLoader loader = clazz.getClassLoader();
>>
>>This allowed the log4j.properties file to be found anywhere in the
>>classpath.
>>
>>It seems that the ClassLoader object can only be retrieved from a
>static
>>initiazation block of a class that is currently being loaded.
>>
>>For example: If we are in class A, and do:
>> ClassLoader loader = A.class.getClassLoader(); it works
>>but if we use any other class:
>> ClassLoader loader = B.class.getClassLoader(); it does not work
>>(returns null)
>>
>>So can the line:
>> ClassLoader loader = clazz.getClassLoader();
>>be changed to:
>> ClassLoader loader = ClassLoader.class.getClassLoader();
>>in some future version of log4j?
>>
>>Dan
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>
>--
>Ceki Gülcü
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
