logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject UGLI -vs- Monitor (was: Re: conversion patterns and caller class information)
Date Tue, 22 Jun 2004 13:44:54 GMT
I completely missed this reply for some reason.  Sorry to bring it up 
again, but just a couple comments...

At 04:04 PM 6/8/2004 +0200, you wrote:
>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.

So it would be better for Ant classes to arbitrarily use Loggers which 
could be named in any which way or even to use arbitrary logging 
implementations in each class (Note: I haven't verified the Ant source to 
see how logging is set up)?  Whatever Ant is doing, the use of a Monitor 
forces all classes to use the same sort of logging mechanism.  Logging 
becomes componentized and consistent.  Anyway, I'm not going to attempt to 
defend Ant logging because I really don't know how it is implemented.  I 
don't really use it much.

>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.

The pattern *is* general, the implementation of the pattern is more 
specific.  Encapsulated within Prevayler, the pattern works right in 
concert with everything else since Prevayler is pretty well componentized 
based on its own defined interfaces.  And it *does* demand less on the 
environment, other than the initial configuration.  But that isn't so hard 
using the PrevaylerFactory which provides defaults for things you don't 
want to set yourself.  The defaults, of course, use component 
implementations which don't require libraries outside of Prevayler.

>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.

Which is why I think we are arguing past each other.  The Monitor *is* 
built into Prevayler.  The Monitor interface is localized, not 
external.  It is how Prevayler provides the user with its internal logging 
messages.  Because the Monitor interface is internal, it removes any 
dependency on an external logging library or set of interfaces like 
UGLI.  I love Log4j, but there are times when I just want to use a piece of 
software and don't care about seeing logging output, yet there is always a 
dependency on Log4j whether I want to use it or not when using Log4j in the 
classic way.  If I don't put it in the classpath, the application 
breaks.  Usually this is not too painful, but is it absolutely 
necessary?  I think the Monitor shows that it is not.

>Basically, using the monitor interface is equivalent to saying screw
>logging, which is btw perfectly OK.

Like I said above, in certain cases, yes.  But keep in mind that this is 
not the author saying "screw logging" and simply removing any sort of 
logging from the software (as does Picocontainer).  This is left up to the 
user.  If they want to see logging, they can see it in any sort of way they 
want.  Heck, they can provide their own Log4jMonitor implementation and 
change the way loggers are named.  How can you argue with the user?  If the 
user doesn't want logging, they are not "wrong".  That's like saying 
because I don't want to... buy a new computer, I am "wrong".  The concept 
doesn't even make sense.  On the other hand, if the author decides to 
"screw logging", you have an argument because the user may want to see what 
is happening and the author is hiding the internal workings of the 
application against the user's wishes.  After all, it is the user who 
counts.  Software may be authored, but if it is not used, it is worthless.

More below...


>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.

No, it was developer consensus that there be no default runtime dependency 
on any logging API and no non-configurable logging 
(ie.  System.out.println()).  That meant either using the Monitor concept 
or removing logging altogether.   The fact that we chose the Monitor rather 
than no logging whatsoever is a clear indication that we found logging to 
be relevant.


>>  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.

What dirt?  What's under the rug?  Oh, you mean...

public class MyClass {
     private static final Logger logger = Logger.getLogger(MyClass.class);
}

versus...

public class MyClass {
     private Logger;

     public MyClass(Logger logger) {
         this.logger = logger;
     }
}

Which one looks more like "dirt under the rug" to you?


>>>>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.

Fine, I'm not arguing about Ant logging.  Like I said, I know very little 
about it.  The Prevayler Monitor interface is perfectly useable under any 
environment you want it to run in and *is* seamless other than the fact 
that if you want to use the Log4jMonitor, you will have to configure 
Prevayler to use it (and make sure Log4j is in the classpath, of course), 
but that is all part of starting up Prevayler.  It would be pretty weak to 
claim that, for this reason, that the Monitor fails to provide "seamless" 
logging integration.

>>>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");

That's certainly better, although the idea of an UGLI adapter for JDK1.4 
logging smells like commons-logging.

>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.

That's great.  Will Log4j-1.3 be UGLI compatible?  When will the other 
API's?  Again, I think the adapter smells like commons-logging and I try to 
stay as far away from that as I can.

>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.

Ok, there's the disconnect.  My question to you is "when will IOC *not* be 
available"?  See the example of MyClass above which takes a Logger as a 
parameter of its constructor.  That's IOC.  The "C" stands for "Control", 
not "Container".  That's why apps written with the idea of using 
Picocontainer, generally, don't depend on Picocontainer.  The container can 
help to do many things that might be consider drudgery or simply help avoid 
writing extra code.  However, you can always do..

o.a.ugli.Logger logger = 
o.a.ugli.LoggerFacade.getLoggerRepository().getLogger("x");
MyClass obj = new MyClass(logger);

Of course the issue here is that the logger is named in one specific 
way.  That's where the Monitor comes in.  UGLI would solve this by 
providing, for instance..

public void debug(Class clazz, Object msg, Throwable t);

Where the Class parameter is the class in which logging is to be provided 
for.  The name of the logger will be obtained from the Class 
parameter.  And that's really what the Monitor does.

   void error(Class clazz, String message, Exception ex) {
       Logger.getLogger(clazz).log(callerFQCN, level, message, ex);
   }

All that said, if UGLI became a universally adopted API, I'd certainly use 
it for my own applications.  The Monitor still wouldn't be obsolete, since 
it would continue to remove any mandatory external runtime dependency, but 
that argument becomes less powerful with a logging API that is a just a few 
K in size.

Jake

>>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: 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


Mime
View raw message