Whether you choose Log to be an interface or an abstract class does not really matter. The point I am trying to convey is that jcl will not be able to abstract more than one logging API. Although desirable, abstraction is not technically feasible.
At 12:59 AM 12/20/2004, Matt Sgarlata wrote:
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.
-- Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
