Hi Jake,

variable. I don't create the monitor in the class itself as is the normal Log4j usage.<<

Yeah, okay, that makes sense for the *component*. But how do you deal with the chicken-and-egg problems that you're inevitably confronted with in the *container*?

Specifically, how do you deal with a need for the container to be able to do things like logging during its *own* start-up and initialisation? Who tells the container how to log?

Once the container is up and running, the Monitor interface idea would obviously work, but the container still has the original problem. Arguably, this is an appreciable gain, in and of itself - rather than 20 components all individually having to worry about how to log while they're getting their feet under them, now only the container has to deal with such issues. But the issues are still there... Aren't they?

Hmmm... I suppose you could design Monitor implementations such that they could be instantiated cleanly via reflection, and then one would just have to have some meta-data source somewhere (properties file, deployment descriptor, whatever) where one configured a property for the container's "logging monitor"... But if one does this, I don't see how such a solution is fundamentally different from the following, which is alleged to be a "bad smell" on Pico Container's Web site...

public class AppleImpl implements Apple { private static Orange orange = OrangeFactory.getOrange(); public Apple() { } // other methods }

Presumably, in this solution, "OrangeFactory" is reading the above-mentioned meta-data source to find out what sort of "OrangeImpl" to create, and then using reflection to do so. So, if the container uses a similar trick to parameterise its own, internal logging, isn't it still suffering from a bad smell?

Cheers, Mark