If we take a concrete example, namely logging in ANT, then one can clearly see that ANT is following a listener pattern (a.k.a monitor pattern). Claiming that the monitor pattern is a general solution to most logging problems is imho not based on reality but on wishful thinking. In the ANT case, ANT *is* the application. It can set up the logging environment as it sees fit. When the Main class in ANT sets the logger listener the rest of the ANT components such as tasks and targets all say Amen, and that's the end of the logging problem. Moreover, ANT already has an event model which is useful independently of its logging aspects, although in the BuildListener case, the interface is tainted by logging-specific methods.
IMHO, the monitor pattern maybe useful under certain circumstances. It is not a universally applicable pattern. I just don't buy the argument that it demands less on the environment and can serve as a more general pattern.
I don't think the unsuspecting library author gains much in swapping the a dependence on the UGLI API on a dependence on the monitor API. It only makes sense if you consider logging as a very secondary feature (which btw might be a well justified hypothesis) and you already have a monitor interface built in your software.
Basically, using the monitor interface is equivalent to saying screw logging, which is btw perfectly OK.
At 01:30 AM 6/8/2004, Jacob Kjome wrote:
If you read Paul Hammant's article as well as http://wiki.apache.org/avalon/AvalonNoLogging carefully, you should realize that the Monitor idea is really about the irrelevance of logging output. The Monitor technique is a way for library authors ignore the logging issue with the option of enabling it if the end user really wants it. The monitor's approach does not solve the problem it claims it solves, it just defers it. Hence, it's appeal to the unsuspecting masses.
Whatever the motivations of Paul Hammant (who is also responsible for AvalonNoLogging, BTW), I don't think that the Monitor makes logging irrelevant. If we didn't want logging at all, we wouldn't be using the Monitor interface in the first place.
Not true. The assumption is that you have a listener interface to begin with.
What this buys us is a way for the user to decide whether they want logging and, if so, what implementation to use (ie. what external libraries do I, the user, want to declare a dependency upon). The Log4jMonitor is there in case they want to use Log4j, in which case they can use their standard Log4j config file and view logging messages from Prevayler just like they do in their own application. They don't need to know anything special about how a Monitor works since it doesn't change the way they think about logging in the first place. Please go into more detail about why a user should have reason to "suspect" anything!
Sweeping the dirt under the rug does not actually clean anything. It just moves the dirt to a less visible place. The unsuspecting masses will say, we can't see the dirt, it must be gone.
Like I said, the above would be just fine, except that the idea that every logging framework out there would implement that interface is unlikely and the fact that the Monitor is meant for internal use (while still being able to use a single Log4j logging configuration chosen by the user just like normal if the Log4jMonitor interface is used).
What a library author needs from the logging API is for it to be
1) non-disruptive
Yep, the Monitor succeeds at this.
2) Integrate seamlessly with the user's existing logging environment
Yep, the Monitor succeeds at this.
Not true. The monitor interface makes logging pluggable as much as logger injection would. However, this does not mean seamless integration within a bigger environment. For example, I don't think it is possible to get Ant logging integrating from the context of a bigger application, say a web-application.
JDK 1.4 logging is unlikely to switch to UGLI but that does not mean that one cannot write an UGLI adapter for JDK 1.4 logging. As for the various Avalon logging APIs, I expect them to *eventually* adopt UGLI, although one can never be sure.
I wonder if we are discussing the same thing? The Monitor doesn't interfere with anything, removes a runtime dependency on any particular logging api except via the user's explicit choice to depend on it, and free's the library author to set up an internal logging paradigm of his/her own choice while, at the same time, leaving the user unaffected.
UGLI is a fine interface, but does create a dependency on an external package (however minimal or trivial one might view that) and it fails to free the library author from a logging paradigm of his/her own choice. UGLI still doesn't solve the Logging API dependency problem. for instance in the classic Log4j usage...
private static final org.apache.ugli.Logger logger = org.apache.log4j.Logger.getLogger(MyClass.class.getName());
Not exactly, it's going to be:
private final o.a.ugli.Logger logger = o.a.ugli.LoggerFacade.getLoggerRepository().getLogger("x");
No dependency on log4j but UGLI alone. The application can configure the UGLI LoggerFacade which logging repository it wants to use in a particular context.
Oh, by the way the LoggerFacade can be static or dynamic, I don't know yet.
What does this buy us? There is now not only a dependency on the Log4j package but also the UGLI package without providing any benefit to the user.... unless you pass in the UGLI Logger via IOC, in which case the UGLI api becomes useful as a Logging implementation-neutral API. Are you following me here? Am I following you?
OK, the IOC approach has the most flexibility. However, we cannot always assume IOC.
Jake
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
