[slf4j-dev] NOPLogger methods are final?

[Eric Crahen]

On 2/15/07, Boris Unckel <boris.unckel.mlg at gmx.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070215/6c0db658/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NullLogger.java
Type: application/octet-stream
Size: 2894 bytes
Desc: not available
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070215/6c0db658/attachment.obj>