Women in Technology

Hear us Roar

  Understanding Classloaders: log4j in a J2EE Environment
Subject:   At first sight I agree, but.......
Date:   2003-04-08 10:46:30
From:   anonymous2
I'm not sure putting the log4j in the .ear file is always the best solution. It seems the obvious thing to do as all the code for your app is in one location.

My problem is to do with the configuration of Log4j and not the classloading. If the config file is also in the .ear then it is pretty much impossible to change the logging config at runtime without re-deploying the application. You can't take advantage of methods like DOMConfigurator.prepareAndWatch(...) as you can't change the xml config file. It's hidden in the ear file.

Another issue is if you wish to initialise log4j yourself and not rely on the default initialisation. Where should you put the code for this one time initialisation? Certainly not in an EJB method.

How have people resolved these issues?

Main Topics Newest First

Showing messages 1 through 1 of 1.

  • At first sight I agree, but.......
    2003-04-11 05:30:55  gvix [View]


    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