commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: [logging] ECL: Log interface vs. abstract class
Date Mon, 20 Dec 2004 15:17:03 GMT

Aren't you assuming that things can be placed in nice orthogonal and
independent boxes?

Let X and Y be logging APIs that JCL attempts to abstract. Let IX be
an interface unique to API X. Let JCL-IX be JCL's mirror of interface
IX. If the end-user sprinkles her code with JCL-IX calls, there are
two possible branches:

1) API X is available, and there no unintended or unforeseen
interactions between JCL-IX and IX then everything will be fine. If
there are unintended or unforeseen interactions, then this usually
takes a long time to discover, let alone to repair. In the mean time,
your users will be pulling out their hair in frustration.

2) API X is unavailable. In that case, JCL might may attempt to
replace the functionality offered by API X with a NOP implementation or
a simple alternative. However, if API X is considered core
functionality, then the promise of abstraction cannot be not fulfilled
without duplicating the code found in API X.

Writing a good facade is much harder than what people realize. In the
case of competing and divergent APIs, it is an impossible one.

At 03:18 PM 12/20/2004, Matt Sgarlata wrote:
>I disagree; different logging APIs can be supported with the addition of 
>new interfaces.  Using this strategy, the set of interfaces that a given 
>Log implementation implements define the set of features which that 
>logging implementation supports.
>Ceki Gülcü wrote:
>>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.
>Ceki Gülcü
>   The complete log4j manual:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message