commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <sgarl...@users.sourceforge.net>
Subject Re: [logging] ECL: Log interface vs. abstract class
Date Sun, 19 Dec 2004 23:59:40 GMT
Ceki Gülcü wrote:
> Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
> domains for categorizing logging statements. When that happens, the
> notion of logging levels will be looked at very differently.
> 
> Commons-logging promises to abstract different logging APIs such as
> log4j, Avalon logkit and java.util.logging API. However, such a task
> is near impossible to fulfill, while Avalon Logkit is nowhere to be
> seen. In the history of software, no one has ever managed to abstract
> competing and divergent APIs without their active cooperation. Chances
> are it won't happen this time around either.
> 
> User who currently use commons-logging are likely to go through a
> lengthy and painful conversion process when they realize that log4j
> offers must-have features.

I think this added functionality that is coming in Log4J demonstrates 
another reason to leave Log as an interface rather than converting it to 
an abstract class.  Assuming we make LocalizedLog an interface that 
extends Log, when Log4J introduces support for their new "domain" 
logging (if you will), JCL can just introduce a DomainLog interface that 
extends Log and has nothing to do with LocalizedLog.  A logging 
implementation may or may not support internationalization, and may or 
may not support this new "domain" concept.  In this way, we can have Log 
implementations describe which features they support by implementing 
certain interfaces and not others.

If Log becomes an abstract class, then instead of just introducing a 
LocalizedLog interface and a DomainLog interface, we would would have a 
factorial explosion of abstract Log subclasses:

DomainLog extends Log
LocalizedLog extends Log
DomainLocalizedLog extends Log

If we need to introduce FeatureNumberThree we will have all the above 
abstract classes plus:

FeatureNumberThreeLog extends Log
DomainFeatureNumberThreeLog extends Log
LocalizedFeatureNumberThreeLog extends Log
LocalizedDomainFeatureNumberThreeLog extends Log

etc.

Conclusion: Switching to an abstract class doesn't just hamper the 
flexibility of users of JCL; it also decreases JCL's ability to expose 
more logging features by simply introducing new interfaces.

> 
>> Matt
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message