On 2/15/07, Boris Unckel <[EMAIL PROTECTED]> wrote:
I think for a common API like SLF4J it is very good to have implementations
final: SLF4Js goal is to be used in libraries, other APIs and applications. If there is need to change things, the interfaces have to be stable. The implementations should still have the chance to be changed WITHOUT heavily caring about possible inherited classes.
This is a "no-op" logger. I've carefully considered the fact that the inherited implementations of all these components do nothing, and now for the purposes of a test case I would like to add some assertions. I.e. this is one major problem in the development of log4j - there is so
much usage that each very little change has to be proven binary compatible. Thousands of people did not care about using just interfaces and the SPI, they just hacked "quick and dirty" with inheritation of classes which were created with internal use intention.
My code is still written only against interfaces. I'm extending an
implementation I've chosen to use for a test case.
public void testWarningsAreLogged() {
final boolean warned[] = new boolean[] { false };
Logger logger = new NOOPLogger() {
public boolean isWarnEnabled() { return true; }
public void warn(String msg, Throwable cause) { warned[0] = true; }
};
// TEST SOMETHING
assertTrue(warned[0], "A warning was not logged");
}
I think this is a faily useful and straightforward test case that I can not
write today.
If someone has need to change something, the license offers full rights to
do that. Make a copy and change it. Although there is the decorator pattern....
I can tell you why I don't want to do the decorator pattern. The Logger and Marker APIs are actually quite lengthy and its more than a few lines of code to implement them. To write the test above I had to create a NullLogger and implement 49 methods that did nothing; which the NOPLogger already does (attached). I don't see any value in keeping the methods of NOPLogger final. -- - Eric
NullLogger.java
Description: Binary data
_______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
