I don't understand your concern about reliance on the thread context class loader. The ServiceLoader mechanism is a well established method for doing this reliably. This happens all over the JDK, from character sets, to encryption schemes. It works very well and gives you a much cleaner separation.
On 2/13/07, Ceki Gülcü <[EMAIL PROTECTED]> wrote:
At 09:40 PM 2/12/2007, Eric Crahen wrote: >On 2/12/07, Ceki Gülcü <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >> >>Given that there seem to be real demand for a standalone slf4j-api.jar(at >>compile time), I think I'll attempt to solve it by having slf4j-api depend >>on a "bootstrap" module, containing a trivial implementation of >>StaticLoggerBinder, just enough to get slf4j-api to compile. Bindings will >>need to provide actual real implementation as they do today. >> >>I think this little change will make life easier for our users. I'll give >>it a shot. As usual, we can revert if need be. > >Wouldn't moving that LoggerFactory I provided earlier solve this? Yes and no. SLF4J does the binding at compile time avoiding reliance on the value of the thread context class loader. >Or is that what you were talking about? No, I am talking about some thing else, an implementation that relies on compile time binding. >-- > >- Eric -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
-- - Eric
_______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
