Log4j and JMX

A correct Logging mechanism / Error Reporting is one of the most vital parts of an IT solution, yet it's one of the most overlooked and let to the individual developer's taste.

This normally leads to frightening GREP nightmares in environments where the application is deployed in a cluster... usually several grepping monkeys (I have been one of them often :o( ) are assigned to the task of grooming the logs in search of error conditions.
 

The adoption of monitoring tools - often grepping logs based on a set of regexps - is normally something which happens very late in the project, and it entails a painful series of flashbacks and retrospectives to remember all the error conditions we have seen in the past, manually troubleshooted and not captured anywhere.

In most projects, logging is configured with a unique log4j.properties or log4j.xml (I prefer the xml).... which is edited by hand and ofter requires a restart of the appserver .... unless you use the propertyconfigurator, which is not something I particularly like. For instance, it becomes impossible to have any automated tests involving logs, because you don't have a way to configure them programmatically. But since logs are Cinderellas, nobody really want to test them.

Anyway I like the idea http://www.theserverlabs.com/blog/2010/04/22/dynamically-changing-log-level-with-weblogic-log4j-jmx-and-wlst/ of using JMX in conjunction with log4j. To be definitely explored in the next project, and that I have seen used in the past.

In the past I have used also a JSP console to change log levels at runtime, something like this:

http://ananthkannan.blogspot.com/2009/10/how-to-change-log-levels-on-fly-using.html