logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject RE: conversion patterns and caller class information
Date Sun, 06 Jun 2004 18:51:11 GMT
At 06:04 PM 6/6/2004 +0200, you wrote:
>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
>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

How much did you read about Picocontainer?  The above code would be changed 

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 

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.


>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message