Hello, and thanks for your reply. My log4j-1.2.8.jar file is in my WEB-INF\lib. But it is also in my j2ee\home\lib, and if I remove it from there I get issues with my JAASUserManager. If I remove it from WEB-INF\lib there is no change in its behaviour.
I believe that oc4j is not using child-first classloading. I found a switch: <web-app-class-loader search-local-classes-first="true" />, but when I use it then I get other issues with my application and can't get far enough to tell whether its fixed the logging. I tried dropping the log4j.properties file into the j2ee\home\lib and it behaves as I'd like now, even though I'm sure that's a rotten way to do it. Question: if I were to use "-Dlog4j.configuration=file", is this a flag I add to the line when I start my server? I tried it and the server didn't like that, so I wonder where I am to use it? J -----Original Message----- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 9:55 PM To: Log4J Users List Subject: Re: How to get rid of the zillions of DEBUG messages? You say log4j.properties is in your WEB-INF/classes directory, but where is log4j.jar? Is it in WEB-INF/lib? And if so, is your server also set up to use child-first classloading behavior like Tomcat is by default? Most servers actually *don't* do this by default. It's usually something you have to turn on. Now, even if log4j.jar is in WEB-INF/lib *and* child-first classloading behavior is enabled, you are still left in the cold if somewhere there is a directory or jar in the classpath that has log4j.xml which is in the default package. I think this is about the 20th time this past week or two that I've brought this up, but I'll say it again. If you want to use the default initialization and you don't want to specify your file via a system property provided at the command line upon JVM startup (something like -Dlog4j.configuration=file:///path/to/config), which would end up applying to every application in the server, then you should use log4j.xml because it gets picked up in preference to log4j.properties if both are found on the classpath. log4j.xml could even be in a parent classloader and will still get used in preference to WEB-INF/classes/log4j.properties when using child-first classloading. Of course, if you aren't using child-first classloading, there's your problem right there. Even if you have log4j.jar in WEB-INF/lib and log4j.xml in WEB-INF/classes, but you also have log4j.jar in some parent classloader, then that instance of log4j will start with the server and every webapp under the server will use it rather than log4j.jar in WEB-INF/lib. And, of course, automatic initialization will have been performed on server startup with a config file that, most likely, is not the one in your webapp. Jake --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
