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:[EMAIL PROTECTED]>[EMAIL PROTECTED]> 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@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 _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
