That's exactly what I was looking to be answered - I didn't think it could co-exist either. I have one more final solution that will allow graceful degredation _without_ classloader problems. I'll post that in a second.
On Tue, Jul 15, 2008 at 12:26 AM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 11:54 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> If we have our own org.slf4j.impl.StaticLoggerBinder that implements >> my desired graceful degredation logic, are we sure this won't override >> a user-configured SLF4J binding? >> >> I think it might because then its a race condition to pick up the >> first org.slf4j.impl.StaticLoggerBinder class found by the class >> loader. > > I don't see how your logic and a regular SLF4J implementation could > coexist. In a simple environment, class path order would decide on > which implementation would be picked. Also, I don't think your logic > makes any sense when picking SLF4J as the logging API. For the > non-sophisticated users that you are worried about, pick one of the > SLF4J implementations and document that it's th one they get. For all > other needs, the regular SLF4J JAR is the one to use. I would think > pretty much every one will end up with the slim JAR anyways, but time > will tell. > > /niklas >
