Understanding Classloaders: log4j in a J2EE Environment
Subject:   At first sight I agree, but.......
Date:   2003-04-11 05:30:55
From:   gvix
Response to: At first sight I agree, but.......


Thanks for the feedback.

You are correct. When you deploy it as an ear file, you lose the ability to change it at runtime. Having said that, you can still configure it at runtime by providing a runtime interface to the log4j API. Remember, log4j can be reconfigured using direct calls to the API. I have myself not tried this, but I believe it can be done. I am also not sure if you can do the same with the exploded format. I would love to hear from somebody who has tried this.

As regards your second issue, if you application has a web part, you can use a startup servlet. If not, you can use a static class that does the initialization for you.

Hope this helps,
Vikram Goyal

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • At first sight I agree, but.......
    2003-04-15 04:23:46  anonymous2 [View]

    I have managed to get Log4J to be configurable at runtime by setting the system property log4j.configuratorClass. This property is used by Log4J to specify the configurator class used during the default initialisation. We then wrote a configurator to allow Log4J to watch the config file for updates.

    This method works fine, but it does mean that this configurator is used for all applications using Log4J on that server. This in turn implies that you have one configuration file for each server (i.e. it applies to all the apps running on that server).

    Whilst it would be nice to separate the logging configuration for each app on a j2ee server, in practise it's not that bad. Our support administrators like to configure logging on a per server basis anyway.