Daniel Wellman wrote:
> The short answer is that most logging tends to be an afterthought rather
> than treated with the same care as the other business-requested
> features. This typically means a proliferation of log statements
> scattered throughout the code. If the logs we're talking about are used
> by the operations group for critical support, then it's important that
> those messages get unit tested. The most common use of Log4j sprinkles
> static method calls to Logger.getLogger() throughout several classes and
> is hard to test. Instead, Freeman and Pryce recommend treating logging
> as a service which gets injected into classes that need it, and unit
> tested that way.

I whole-heartedly agree that logging should be a first-class user story.
Too many apps fill up the log with trivia, yet don't contain the
information needed for in-production fault isolation.

If you've already got code that fetches a logger rather than having one
injected, it's quite easy under Log4J to programmatically insert your
own appender. The static getLogger() calls are just easy entry points
into a very configurable system.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------