[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    RE: Loader class
From:       "Dan Sieroka" <sieroka () platespin ! com>
Date:       2001-05-28 13:51:20
[Download RAW message or body]

In order to simplify the deployment of our software, we have moved all
of our class files into one jar (or directory), and then moved all of
our properties files into another directory, ie. path/to/properties and
added that to the classpath.  In 0.9.1, log4j finds the property file,
in 1.1.1 it doesn't.

I'll try it again sometime this week to make sure.

Dan

-----Original Message-----
From: Ceki Gülcü [mailto:cgu@qos.ch]
Sent: Monday, May 28, 2001 9:49 AM
To: LOG4J Developers Mailing List
Subject: RE: Loader class



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:cgu@qos.ch]
>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: log4j-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>--
>Ceki Gülcü
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

--
Ceki Gülcü


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


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

[prev in list] [next in list] [prev in thread] [next in thread]