Robert, Thanks for the response, its true that when I removed log4j.properties file that we were specifying in our application..Still the WAS server did not complain infact the logging seems to be perfect and I dont see any DEBUG messages.. Not sure where its reading the log4j.properties..
Anyways its not the JCL issue anymore.. Thanks, -----Original Message----- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Monday, February 06, 2006 3:25 PM To: Srilatha Alase Cc: Jakarta Commons Users List Subject: RE: RE:Commons-logging WSAD5.1 On Fri, 2006-02-03 at 11:19 -0600, Srilatha Alase wrote: > Robert, > thanks for correcting..good news is that It worked! I'm able to start and > run my application. > but I'm again back to square one :( the point is not where you are but what we have learnt :) we now now that you current configuration of JCL is bridging correctly to log4j. therefore, you problems are on the other side of the bridge, with log4j. you know need to do something similar for log4j: find each and every log4j.properties file and remove each one until log4j starts printing it's warning. then add in a single log4j.properties file to a known location. > I'm still seeing some messages when I start the server..so attached is the > message list. > > Our project was implemented around in 2002.They used different ways to get an > instance of > a log.. > One of the ways was to create a custom Class called common.util.Debug. Please > find the attached Debug class. > Now we have some classes(ex:MyTestDAO) calling this Debug class to do the > logging.(Its not pretty.. > but thats how they implemented). i understand that it's not your fault but for the record note also that you'll find the design will lead to a performance degradation: string concatenation is slow. the guard call (for example, isDebugEnabled) is intended to allow slow operations such as string concatenation to be avoided. > So In the log4j.properties I kept both the calling classes and the Debug > class to WARN. > all the classes that were using or getting log Instance in a normal way have > no problems. great > But the classes > which are calling Debug classes to log the messages are still printing out > the log messages. can't see any obvious cause in the class is it possible that common.util.Debug is being loaded by a different classloader? in this case, it is possible that log4j will be picking up a different log4j.properties file (see above). you can test this by removing the log4j.properties file that you use for the classes that work. if common.util.Debug still logs then it is using a separate properties file. > Thanks for all your help! sorry for being so slow (not been too well over the weekend) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
