[slf4j-dev] Consolidating the LoggerFactory / A better plugin mechanism

[Ceki Gülcü]

Earlier versions of SLF4J parsed properties files and instantiated an 
ILoggerFactory similar to the way sun.misc.Loader does it. SLF4J "evolved" 
into a more primitive solution to make debugging easier (but harder on 
SLF4J developers).

I am more interested in refining the current approach as opposed to trying 
something more innovative. OK?

At 09:18 PM 2/19/2007, Eric Crahen wrote:
>On 2/19/07, Ceki Gülcü <<mailto:listid at qos.ch>listid at qos.ch> wrote:
>>One of the reasons why SLF4J is relatively successful is due to its
>>simplicity. SLF4J only does static-binding and ito fails-fast. If
>>there is no slf4j-binding available SLF4J prints an error message and
>>dies immediately (it fails-fast).
>
>Still possible with the Service API; except you could have much better 
>error messages than is technically possible with the current solution.
>
>>The ServiceProvider interface is only available in JDK 1.6.
>
>It is available since 1.4 as sun.misc.ServiceLoader, even in 1.6
>
>>Moreover, it used the thread context class loader. SLF4J is not going to 
>>go on
>>that road in the immediate future.
>
>I really think it would be worth everyone while if time is taken at some 
>point to explore this solution. I get the strong sense there is an 
>unfounded fear of ClassLoaders due to past bad experiences with them; 
>ClassLoader != problems. I look forward to seeing some serious 
>consideration given to this option in the future, instead of a knee jerk 
>"classloader-bad!" response. I think I've provided an enormous amount of 
>information on the subject that should be plenty to develop a working 
>solution as soon as people are willing to give it a try.
>
>Thanks,
>
>--
>- Eric
>_______________________________________________
>dev mailing list
>dev at slf4j.org
>http://www.slf4j.org/mailman/listinfo/dev

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch