First: it is normally not necessary to call BasicConfigurator.configure(); mainLogger.setLevel(Level.ALL);
if you have set up the logging framework properly through config file. Such code you need only in special circumstances. It's just enough to call Logger.getLogger( <name> ). You can do this static in the class, on class instances or even local within methods. Log4j does the configuration automatically the first time a logger is fetched if it finds a config file within the classpath. The statement "Logger mainLogger=Logger.getLogger(this.getClass());" will fetch a logger which is named by the fully qualified classname of "this", i.e. "com.myCompany.myPackage.MainClass". The dots in the name describe the hierarchy structure. You are free in choosing your logger names and hierarchy structure. But following the convenience to use the package/class name as hierarchy structur offers several benefits for fintuning your logging output (see example below). A Logger declared in config file follows the same rule. The repository holds all configured Loggers and all loggers fetched by code within the same hierarchy. Logging calls to loggers which were fetched by code and have no corresponding logger within the config file will climb up the logging hierarchy until the root logger, which is the unnamed parent of all loggers in the hierarchy. Each logger on this way up which has one or more appenders attached will serve this appenders with the logging call. This climbing up can be avoided if you declare a logger's attribute "additivity=false". A logging call will not climb further if it reaches a Logger with this attribute set. An example: Your application uses packages like: - com.myCompany.myPackage - com.myCompany.myOtherPackage - com.myCompany.myPackage.security - com.myCompany.utils - org.apache.commons.net Your utils package is already well tested, you dont want any debug statements from it, INFO is enough. But all log statements coming from your app (myPackage, myOtherPackage, and below) you want on level DEBUG, except the messages from securitypackage which you want only see WARN and ERRORS. You are not interested at all in log statements coming from commons.net. So you would declare following loggers: - a root logger with level INFO - a logger com.myCompany with level DEBUG, additivity = false - a logger com.myCompany.utils with level INFO, additivity = false - a logger org with level OFF, additivity = false Lets say, all this declared logger have only one appender (i.e. to Console). A logging call to a logger fetched by com.myCompany.myPackage.MainClass (this is also the name of this fetched logger) will climb up the hierarchy until it finds the declared Logger com.myCompany which has level DEBUG. On your console you therefore will see this statement. Because additivity of this Logger is false, the log statement will not climb further. A call made by a logger logger com.myCompany.utils.StringFormat would find the declared logger com.myCompany.utils which has level INFO. Therefore debug statements from this whole package will not show up in console. Any statements done by a class whose name starts with "org" will not show at all. Going a step further. You want to log security issues to a separate file. So you declare a logger - com.myCompany.myPackage.security with level WARN to which you attach a file appender. Additivity is by default true. Logging calls to a logger fetched by com.myCompany.myPackage.security.MyLoginVerifier would behave like this: on level WARN it will show in the file and in the console, on level DEBUG only on console. One day you have problems with the ftp module of the apache.commons.net. So you would declare a new logger - org.apache.commons.net.ftp with level DEBUG, additivity = false in order to see the log outputs of this package (I dont know if there are any, it's just a sample). Hope this helps. Heri --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
