I am not aware of this problem. Since WL 7.0 uses log4j in some of its own components, I am guessing a class loader problem. Do you have log4j-x.jar in a number of places? Have you checked the WL 7 database?
At 15:42 26.11.2002 -0500, you wrote:
Hello. I'm having a problem with log4j that is absolutely baffling me. If anybody has so much as a theory for what I'm seeing, I'd love to hear it.I'm developing a web app running under BEA Weblogic 7.0, and I'm trying to set up log4j as my logging mechanism. When I initially start the server, all is well; log4j works perfectly. However, when I re-deploy my app -without- bouncing the server (the project is set up to be hot-deployable), log4j (mostly) dies. I get no logging messages whatsoever from -any- Logger instance anywhere in the application (with a single exception -- I'll get to that below). I'm not seeing any error messages, and setting log4j.debug=true in my properties file didn't reveal anything worth knowing. The loggers are set to send output to the console. System.out.println() calls always work. I have confirmed that the app is finding the correct properties file each time it restarts, and is parsing the data there properly. I inserted a call to LogManager.shutdown() in the PlugIn.destroy() method, which had no discernable effect. The only exception to this behavior is the Logger associated with the application's PlugIn class; when the application re-starts, I get a SINGLE log message telling me the code has exited the "init" method. I receive no other log messages until I bounce the server -- not even from the PlugIn Logger. Any ideas? -- Pete Butler Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
