At 11:59 AM 6/6/2004 +0200, you wrote:

Ok, that brainfart was a bit embarrassing! Of course you are right and it works just fine. I've given the above advice before to others and yet I didn't think about using it myself. Ug!!!

A single monitor is handed to, essentially, a container which then provides this component to all classes in the framework that require it. In each class that will use the monitor, I just provide a Monitor instance variable. I don't create the monitor in the class itself as is the normal Log4j usage. It it up to the user to configure a Monitor implementation (or get a default backed by either nothing or System.out) for the container and the container will provide it to any class that needs it. This way the user has full control over the components rather than the programmer defining components inside the class outside of the control of the user. It's all about IOC (Inversion of Control). You may have read about this stuff before in articles about Picocontainer ( http://www.picocontainer.org/ ) and Spring Framework ( http://www.springframework.org/ ), to name only two. Technically, we aren't using either of these right now, but the same principal applies.

Besides the user having control over components, this completely removes any runtime dependency on Log4j (or any other logging framework) unless one explicitly configures the app to use the Log4jMonitor implementation. Unlike commons-logging where you are just trading a dependency on Log4j specifically for a dual dependency on commons-logging plus some logging implementation such as Log4j or JDK1.4 logging, there is no dependency whatsoever unless it is desired.

Hope that makes sense.

Jake