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: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
