You can take a look at the RespoistorySelector stuff that is part of log4j. It is meant to address these kind of scenarios in server deployments. A thread or JNDI based implementation of a RepositorySelector may help you solve this issue....
-----Original Message----- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 8:17 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Bummer. I think I'm in trouble, then. The app is going to be running on a common server with several other apps that use log4j. In fact, our company's common error handling component is based on log4j. I'm going to have to do some work with our server guys on this one. Thanks for your help. -----Original Message----- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 8:50 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic The problem is that it is using the java jvm class-loader [using [EMAIL PROTECTED] There is a class either in your system or server class-path attempting to initialize log4j prior to your Struts stuff. Once in a web-app or enterprise-app, the class loader would be something named WLContextClassLoader (I forgot the exact class name, but its a bea supplied class). Are you defining anything in the system or server class-path which uses log4j (or even commons-logging)? That would be a problem in weblogic. Even to the point of security realms. I had to end up removing all log4j usage from our custom security realm beacause it got initialized before any apps (and because weblogic loads all sec-realm classes on using the jvm class-loader). You pretty much have two options... 1) Seek out all libraries using either log4j/commons-logging and moving them from the server class-path to the appropriate app-specific directory. 2) Place your log4j.properties file also in the system/server class-path. Note that just about everthing from the jakarta uses either one of these two logging libraries... -----Original Message----- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 7:39 AM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Well, I seem to have really hit a brick wall on this one. I turned log4j.debug on and got: log4j: Trying to find [log4j.properties] using [EMAIL PROTECTED] class loader. log4j: Trying to find [log4j.properties] using ClassLoader.getSystemResource(). log4j: Could not find resource: [log4j.properties]. I've verified that the properties file is in the war file's WEB-INF/classes directory. There are no log4j.properties files in the classpath anywhere. I am using Weblogic 7.0. I wonder if this might have something to do with using a managed server. Maybe I'll ask BEA. -----Original Message----- From: Steve Ebersole [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 5:52 PM To: Log4J Users List Subject: RE: Picking up wrong properties file in Weblogic >> Does this mean its not finding the properties file? Yes So the file is named log4j.properties or log4j.xml and is located in the war's WEB-INF/classes directory? That's strange, it should find it. Have you tried with log4j.debug set to true? You can try placing log4j.jar and the config file in the ear's root and include manifest Class-Path entries in the manifest of the included wars and ejb-jars. Thats what I do, so I know that works. Also, which version of weblogic. I'm using 6.1sp4, and its worked fine for me. Wasn't their a version where weblogic was using log4j? Maybe 7.x? -----Original Message----- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 1:33 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic The directory was in the system classpath. I took it out, and now I get a "No appenders could be found for category (root)." message. Does this mean its not finding the properties file? To answer the other questions, this is a Struts application, and I'm in an Action class in the war file. I haven't gotten to logging in the EJB jar file yet. -----Original Message----- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 2:23 PM To: 'Log4J Users List' Subject: RE: Picking up wrong properties file in Weblogic Is that directory on the classpath somewhere higher than the weblogic app classloader? For example is it on the system classpath or server classpath? Where is the class which triggers log4j initialization? Is it contain within the war file? If, for example, and ejb component is the first to reference log4j, it would not be able to see the stuff in the WEB-INF/classes directory. What else is inside the ear file? Is everything in the ear supposed to share that log4j config? -----Original Message----- From: Crumbo, Brian [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 12:48 PM To: '[EMAIL PROTECTED]' Subject: Picking up wrong properties file in Weblogic I have deployed an application as an ear file to Weblogic. The war file within the ear file contains the log4j.properties file in the WEB-INF/classes directory, and the log4j.jar in the WEB-INF/lib directory. My understanding is that log4j should pick up the log4j.properties file from the WEB-INF/classes directory by default. However, my application, for some unknown reason, is picking up a log4j.properties file from elsewhere on my machine...from a directory that contains a Java application that has not been deployed. Anybody know why log4j would be going outside the web app to pick up another properties file? --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]
