On first blush, the configuration looks right. You might try adding -Dlog4j.debug=true to your startup and see if anything in the configuration debugging indicates a problem.
What's the environment for this? Is it a standalong Java application or are you running in an application server (Tomcat, JBoss, etc.)?
A silly question, but you are actually logging INFO level messages somewhere, right? Also, have you tried removing commons-logging from the mix and, for test purposes, use the log4j API directly?
Main Topics
Browse All Topics





by: marklorenzPosted on 2007-08-25 at 08:08:49ID: 19768125
Use Logger.getLogger( MyClass), as explained here:
sampleapp. MyClass") method. This logger will implicitly inherit from its nearest existing ancestor (maybe com.foo.sampleapp or com.foo or ...; or root logger if none exists), follow the same parent-child relationship as the class-subclass they log and have same package hierarchy as these classes.
pen/articl e.php/3097 221
Each class in the Java application being logged can have an individual logger assigned to it or share a common logger with other classes. One can create any number of loggers for the application to suit specific logging needs. It is a common practice to create one logger for each class, with a name same as the fully-qualified class name. This practice helps organize log outputs in groups by the classes they originate from, and identify origin of log output, which is useful for debugging.
Log4j provides a default root logger that all user-defined loggers inherit from. Root logger is at the top of the logger hierarchy; in other words, root logger is either parent or ancestor of all logger objects created. If an application class doesn't have a logger assigned to it, it can still be logged using the root logger.
For example: A class MyClass in com.foo.sampleapp application package can have a logger named com.foo.sampleapp.MyClass instantiated in it by using the Logger.getLogger("com.foo.
http://www.developer.com/o