This seems perfectly reasonable to me. If the underlying logging implementation doesn't support internationalization, then the log messages aren't internationalized. Of course, if you've gone to all the trouble of making your message internationalized, I would expect this would narrow down the field of logging implementations you chose from :)
I hope I'm not being argumentative or dense. I'm really just trying to make a case for using interfaces rather than abstract classes. My point earlier was simply that the more features are supported by JCL, the harder it will be to squeeze them into some type of abstract class hierarchy and the more compelling an interface-based abstraction layer is.
Matt
Ceki Gülcü wrote:
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]
