Hi Jake,
>>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.<<
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?
Well, if you are talking about Picocontainer, it doesn't have any logging. You'll have to ask the Picocontainer developers why. And keep in mind that the Monitor interface is internal to Prevayler (the app I'm working on), so the container has no interest in it anyway.
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?
Since we don't actually use an IOC container, but rather simply pass the Monitor to each class that needs it via its constructor, neither the non-existent container has this problem nor the internal code. Currently, to configure Prevayler, one uses the PrevaylerFactory class. You are right, though. The PrevaylerFactory won't be able to log until a Monitor has been configured, other than using some default temporary Monitor backed by System.out. However, since the real guts of Prevayler have nothing to do with PrevaylerFactory, this doesn't concern me much.
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?
How much did you read about Picocontainer? The above code would be changed to...
public class AppleImpl implements Apple {
private final Orange orange;
public Apple(Orange orange) {
this.orange = orange;
}
// other methods
}The container is configured via a script. You ask for an Apple instance and one is given to you by the container with all dependencies provided for you. No matter what the container is doing under the covers, you don't have to deal with it keeping any theoretical "code smell" localized and out of your own code. Besides, you can do all this without the container by doing..
Apple apple = new AppleImpl(new OrangeImpl());
This code is clean, pure, and flexible. Please read more about Picocontainer/Nanocontainer before asking more questions about IOC here. Actually, I don't want to get into a big discussion about IOC on this email list. Nor should I be considered an expert on the topic. Post to the Picocontainer list.
Jake
Cheers, Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
