[slf4j-dev] Review of slf4j

[Ceki Gülcü]

Niclas,

Thank you for suggesting this new approach which is probably more natural. 
It has the advantage of using only perfectly compilable code (convenient), 
in contrast to the current approach which requires some processing for the 
creation of compilable java code (inconvenient). On the other hand, your 
approach duplicates the LoggerFactory class for each implementation (more 
error-prone). Thus, each implementation can choose to "enhance" the 
LoggerFactory class if it wants to, which is not good. The existing 
approach automates the process, so it is probably less error-prone.

I'll make sure to keep your approach in mind in case the existing approach 
turns out to be a hurdle.

More below.

At 07:46 5/7/2005, Niclas Hedhman wrote:
>On Friday 06 May 2005 22:11, Ceki Gülcü wrote:
> > In the current code, only a single world needs to be substituted during the
> > build process. If LoggerFactory+LoggerFactorAdapter+ImplFA where collapsed
> > into LoggerFactory, then the amount of code that would need to be
> > substituted at build time would be "large", resulting in a more complicated
> > build file.
>
>Really. It doesn't seem so to me. Perhaps because we view it from different
>perspectives, I guess.
>
>IMHO, if you created a separate project for each Logger provider
>implementation, and each one had its own LoggerFactory (big deal), the code
>that currently sits in the FactoryAdapter will instead sit in the
>LoggerFactory itself as private methods, and the four tiny common methods in
>LoggerFactory would call them directly.
>
>Then you don't need any Ant filtering in your sources at all, which should
>make for an easier build system, not a bigger one.
>
>
>sflf4j
>   api
>     src/java
>       org/slf4j/ULogger.class
>       org/slf4j/MessageFormatter.class
>   jdk14logging
>     src/java
>       org/slf4j/LoggerFactory.class
>       org/slf4j/Jdk14Logger.class
>   log4j
>     src/java
>       org/slf4j/LoggerFactory.class
>       org/slf4j/Log4jLogger.class
>   simple
>     src/java
>       org/slf4j/LoggerFactory.class
>       org/slf4j/SimpleLogger.class
>   nop
>     src/java
>       org/slf4j/LoggerFactory.class
>       org/slf4j/NopLogger.class
>
>or something like that.
>
>
>OTOH, "other" implementations can do whatever they like, no need to follow 
>the
>same pattern as you do, right :o)

After I wrote my previous message, I realized that implementors were not 
really obliged to follow the same patttern. They could follow a different 
pattern by adapting their build file if they wanted to. My recent 
experiences with log4j have shown that the SLF4J build style requires a 
little getting used to, but otherwise works ok. IMO, the process just needs 
to be documented properly.


>Cheers
>Niclas

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/