[slf4j-dev] Rearranging classes

[Eric Crahen]

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ü <listid at qos.ch> wrote:
>
> At 09:40 PM 2/12/2007, Eric Crahen wrote:
> >On 2/12/07, Ceki Gülcü <<mailto:listid at qos.ch>listid at qos.ch> 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
> dev at slf4j.org
> http://www.slf4j.org/mailman/listinfo/dev
>



-- 

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070213/7fdc0a76/attachment.htm>