As you say, this don't prevent Log4J from working. But these 2 lines are really annoying as my app is a server app, which is run in background as a daemon on Linux. Thus, they are outputed from System.err, and I can't guarantee that production tasks in production env which will use this server will not require stop on standard error output. Moreover, this is not really reassuring from a server that the firts 2 lines you have talks about WARNING ... :D
Then I can't rely on self programmatically controled log ignition because I just want Torque operations to be logged like this. So Torque should handle Log4j properties loading (via commons-logging API), I can't control that, except editing commons-logging properties, which are by the way quoted earlier in my mails. BUT BY THE WAY ! I've found something which make things working. As log4j was complaining about lack of appender for org.apache.commons.somepackage.someclass, I just added this to log4j.properties : log4j.category.rootCategory = ALL, org.apache.torque log4j.category.org.apache.commons = ALL, org.apache.torque THIS IS WORKING ! But it still think that's a Torque/commons-logging bug, whih is not correctly handling Log4j config. On Thu, Jul 31, 2008 at 17:29, Naveen Murthy <[EMAIL PROTECTED]>wrote: > Actually, i dont think those 2 lines coming on ur stdout > means - "log4j will not work for you" > ... -- Pierre. Some people, when confronted with a problem, think "I know, I'll use XML". Now they have two problems. -- Jamie Zawinski / James Robertson
