James is right, as usual. Log4j config files are always looked up in the default package and will be looked up according to the classloader behavior you are using. For instance, here's how I set up my Tomcat server...
common/classes/log4j.xml common/lib/log4j.jar I use the above for the server's own logging as well as apps that don't provide a log4j.jar in their WEB-INF/lib (and when no repository selector is being used such as the ContextJNDISelector). For apps where I want to define my own logging separate from the server, I put log4j.jar in WEB-INF/lib and log4j.xml in WEB-INF/classes. Note that it is *very* important that you include your own config file in WEB-INF/classes so that autoconfiguration doesn't use the config file stored in CATALINA_HOME/common/classes. Even if you perform manual configuration (such as at application startup in a ServletContextListener), you'd be wise to include a dummy log4j.xml in WEB-INF/classes just to make sure you don't inherit configuration from a parent classloader, because autoconfiguration will run before any manual configuration has a chance to run. This also illustrates why I always urge users to move to the XML config format. XML config files are used in preference to properties config files. Even if you put log4j.properties in WEB-INF/classes and log4j.jar in WEB-INF/lib, Log4j autoconfiguration will use a log4j.xml file found in CATALINA_HOME/common/classes rather than log4j.properties in WEB-INF/classes even though Tomcat implements child-first classloading behavior. If you get nothing else out of this email, please remember to move to using log4j.xml rather than log4j.properties. It will save you all kinds of trouble! So, it all depends on what you are trying to do an what classloading behavior is implemented (and whether or not you are using a repository selector). And it depends on what perspective you are coming from; the appserver's perspective or the app's perspective. Evaluate your environment's behavior and logging needs and put your config files wherever they are needed. Jake Quoting James Stauffer <[EMAIL PROTECTED]>: > For automatic configuration it should be in the classpath. Put it in > the shared classpath (i.e. tomcat/common/classes) if you want to > configure every app. Put it in your app classpath (i.e. > WEB-INF/classes) if you want to configure only your app. Where you > put it affects where your log4j.jar should go (I think). > > On 2/7/06, kameron cole <[EMAIL PROTECTED]> wrote: > > I've searched wide for the answer of where to put the log4j.properties file > > in a J2EE system. It's kind of sad to me that none of the articles begins > > to address this really essential part of the set up. > > > > in one obscure post, someone said a "quick fix" was to put it in one of the > > extension classloader folders for the various appservers. can't really be > a > > good thing, since it would affect everybody else's log4j. still, it does > > work. > > > > so, it's not a problem that I don't understand the classpath - it's that > > log4j looks somewhere, not everywhere, for a file called log4j.properties. > > someone must know that exact place where the log4j designers intended to > put > > that file. > > > > thank you for any and all answers. > > > > -- > > yours, > > k. > > > > > > > -- > James Stauffer > Are you good? Take the test at http://www.livingwaters.com/good/ > > --------------------------------------------------------------------- > 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]
