log4j/commons-logging issue?

Discussion in 'Java' started by Facade, Oct 1, 2008.

  1. Facade

    Facade Guest

    Hi - I am deploying a war file to tomcat, and within the war there is
    a jar file that uses log4j (via commons-logging). However I keep
    getting

    log4j:WARN No appenders could be found for logger
    log4j:WARN Please initialize the log4j system properly.

    The log4j.properties file is on the root of my jar file, and when I
    did a
    System.out.println(MyClass.getClass().getClassLoader().getResource("log4j.properties"))
    I can see the file in my Jar file.

    Whats wrong? Why can't JCL/Log4J see the same file?

    Thanks.
     
    Facade, Oct 1, 2008
    #1
    1. Advertising

  2. Facade

    Mark Space Guest

    Facade wrote:
    > Hi - I am deploying a war file to tomcat, and within the war there is
    > a jar file that uses log4j (via commons-logging). However I keep
    > getting
    >
    > log4j:WARN No appenders could be found for logger
    > log4j:WARN Please initialize the log4j system properly.
    >
    > The log4j.properties file is on the root of my jar file, and when I
    > did a
    > System.out.println(MyClass.getClass().getClassLoader().getResource("log4j.properties"))
    > I can see the file in my Jar file.
    >
    > Whats wrong? Why can't JCL/Log4J see the same file?
    >
    > Thanks.


    Google?

    http://logging.apache.org/log4j/1.2/manual.html

    Quote:

    Default Initialization Procedure

    The log4j library does not make any assumptions about its environment.
    In particular, there are no default log4j appenders. Under certain
    well-defined circumstances however, the static inializer of the Logger
    class will attempt to automatically configure log4j. The Java language
    guarantees that the static initializer of a class is called once and
    only once during the loading of a class into memory. It is important to
    remember that different classloaders may load distinct copies of the
    same class. These copies of the same class are considered as totally
    unrelated by the JVM.

    The default initialization is very useful in environments where the
    exact entry point to the application depends on the runtime environment.
    For example, the same application can be used as a stand-alone
    application, as an applet, or as a servlet under the control of a
    web-server.

    The exact default initialization algorithm is defined as follows:

    1. Setting the log4j.defaultInitOverride system property to any
    other value then "false" will cause log4j to skip the default
    initialization procedure (this procedure).
    2. Set the resource string variable to the value of the
    log4j.configuration system property. The preferred way to specify the
    default initialization file is through the log4j.configuration system
    property. In case the system property log4j.configuration is not
    defined, then set the string variable resource to its default value
    "log4j.properties".
    3. Attempt to convert the resource variable to a URL.
    4. If the resource variable cannot be converted to a URL, for
    example due to a MalformedURLException, then search for the resource
    from the classpath by calling
    org.apache.log4j.helpers.Loader.getResource(resource, Logger.class)
    which returns a URL. Note that the string "log4j.properties" constitutes
    a malformed URL. See Loader.getResource(java.lang.String) for the list
    of searched locations.
    5. If no URL could not be found, abort default initialization.
    Otherwise, configure log4j from the URL. The PropertyConfigurator will
    be used to parse the URL to configure log4j unless the URL ends with the
    ".xml" extension, in which case the DOMConfigurator will be used. You
    can optionaly specify a custom configurator. The value of the
    log4j.configuratorClass system property is taken as the fully qualified
    class name of your custom configurator. The custom configurator you
    specify must implement the Configurator interface.
     
    Mark Space, Oct 1, 2008
    #2
    1. Advertising

  3. Facade

    Facade Guest

    On Oct 1, 2:37 pm, Mark Space <> wrote:
    > Facade wrote:
    > > Hi - I am deploying a war file to tomcat, and within the war there is
    > > a jar file that uses log4j (via commons-logging). However I keep
    > > getting

    >
    > > log4j:WARN No appenders could be found for logger
    > > log4j:WARN Please initialize the log4j system properly.

    >
    > > The log4j.properties file is on the root of my jar file, and when I
    > > did a
    > > System.out.println(MyClass.getClass().getClassLoader().getResource("log4j.properties"))
    > > I can see the file in my Jar file.

    >
    > > Whats wrong? Why can't JCL/Log4J see the same file?

    >
    > > Thanks.

    >
    > Google?
    >
    > http://logging.apache.org/log4j/1.2/manual.html
    >
    > Quote:
    >
    > Default Initialization Procedure
    >
    > The log4j library does not make any assumptions about its environment.
    > In particular, there are no default log4j appenders. Under certain
    > well-defined circumstances however, the static inializer of the Logger
    > class will attempt to automatically configure log4j. The Java language
    > guarantees that the static initializer of a class is called once and
    > only once during the loading of a class into memory. It is important to
    > remember that different classloaders may load distinct copies of the
    > same class. These copies of the same class are considered as totally
    > unrelated by the JVM.
    >
    > The default initialization is very useful in environments where the
    > exact entry point to the application depends on the runtime environment.
    > For example, the same application can be used as a stand-alone
    > application, as an applet, or as a servlet under the control of a
    > web-server.
    >
    > The exact default initialization algorithm is defined as follows:
    >
    >     1. Setting the log4j.defaultInitOverride system property to any
    > other value then "false" will cause log4j to skip the default
    > initialization procedure (this procedure).
    >     2. Set the resource string variable to the value of the
    > log4j.configuration system property. The preferred way to specify the
    > default initialization file is through the log4j.configuration system
    > property. In case the system property log4j.configuration is not
    > defined, then set the string variable resource to its default value
    > "log4j.properties".
    >     3. Attempt to convert the resource variable to a URL.
    >     4. If the resource variable cannot be converted to a URL, for
    > example due to a MalformedURLException, then search for the resource
    > from the classpath by calling
    > org.apache.log4j.helpers.Loader.getResource(resource, Logger.class)
    > which returns a URL. Note that the string "log4j.properties" constitutes
    > a malformed URL. See Loader.getResource(java.lang.String) for the list
    > of searched locations.
    >     5. If no URL could not be found, abort default initialization.
    > Otherwise, configure log4j from the URL. The PropertyConfigurator will
    > be used to parse the URL to configure log4j unless the URL ends with the
    > ".xml" extension, in which case the DOMConfigurator will be used. You
    > can optionaly specify a custom configurator. The value of the
    > log4j.configuratorClass system property is taken as the fully qualified
    > class name of your custom configurator. The custom configurator you
    > specify must implement the Configurator interface.


    Hi Mark,
    Google actually did not help, reason being, in my case the file is
    already in the class path where as the stated solutions normally
    suggest to add the file to the class path.
    Thanks for the details on how log4j configures itself, but as I
    said earlier, I am using commons-logging - which should take care of
    configuring the log4j subsystem. Only thing else I can think of is,
    apart from having log4j.properties in my jar file (where the actual
    code doing the logging resides), I could attempt to put in WEB-INF/ -
    all though technically speaking, the Classloader that loads the files
    from the jar should be the same one that loads the War file.

    --abbas
     
    Facade, Oct 1, 2008
    #3
  4. Facade

    Arne Vajhøj Guest

    Facade wrote:
    > Hi - I am deploying a war file to tomcat, and within the war there is
    > a jar file that uses log4j (via commons-logging). However I keep
    > getting
    >
    > log4j:WARN No appenders could be found for logger
    > log4j:WARN Please initialize the log4j system properly.
    >
    > The log4j.properties file is on the root of my jar file, and when I
    > did a
    > System.out.println(MyClass.getClass().getClassLoader().getResource("log4j.properties"))
    > I can see the file in my Jar file.
    >
    > Whats wrong? Why can't JCL/Log4J see the same file?


    If I were to guess then log4j gets loaded by one of the parent
    classloaders and that does not have your jar file with log4j.properties
    in its classpath.

    Arne
     
    Arne Vajhøj, Oct 11, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    829
    Eddie McCreary
    Oct 24, 2003
  2. James Zhou

    Commons logging question

    James Zhou, Dec 16, 2004, in forum: Java
    Replies:
    3
    Views:
    399
    Ryan Stewart
    Dec 18, 2004
  3. Replies:
    0
    Views:
    568
  4. thiaga
    Replies:
    1
    Views:
    1,685
    Roland de Ruiter
    Jul 20, 2006
  5. Gianni Galore
    Replies:
    0
    Views:
    1,293
    Gianni Galore
    Sep 8, 2010
Loading...

Share This Page