On Mon, Jul 14, 2008 at 4:49 PM, Jeremy Haile <[EMAIL PROTECTED]> wrote: >>> Actually thinking for alternatives rather than just shooting it down >>> because it might not fit one's mental model is what I appreciate most. >>> "I don't want to try it", without alternatives or thinking through >>> other options is what I found very frustrating and fueled much of my >>> persistence. > > I find it somewhat offensive that you think anyone's opinion on this list is > just "I don't want to try it", as if they haven't thought through other > options and made a value decision on what the best solution here is. This > isn't just "trying something" - this is making a decision about how logging > works in JSecurity.
I said "thinking for alternatives.". Alan and Peter gave an alternative, but I didn't hear any other alternatives from other nay-sayers, hence my frustration. When you have a superset of functionality that is dead easy to integrate, easy to use, requires little or no maintenance, and only enhances functionality and eliminates dependencies and _still_ turn it down, then there has to be some exceptional arguments to support the reason. And you know what? We've been using Commons Logging for 4 years. Not once have we received a single issue reported or even a mailing list thread or forum post saying that the JCL Classloading is hurting someone. My solution, albeit with some minor modifications to ClassUtils (that need to happen anyway, regardless of this issue or not), would still be even more robust because it still relies on SLF4J when possible. I bet we could go another 4 years or maybe indefinitely before anything even surfaces about logging... > > There have been many compelling arguments as to why we should use SLF4J vs a > proprietary logging abstraction layer. I don't think anyone is arguing for > one side or the other here without taking these arguments into account. > > The idea of bundling in the SLF4J API has been mentioned many previous > times. I'm fine with creating a normal jar and a normal jar + slf4j api > bundled in. This makes it easy to just include the uber jar in projects > that don't want to manually include SLF4J. > > I haven't heard any arguments for why including SLF4J wouldn't work or poses > a real problem that are compelling to me. So are you (or anyone else for that matter) telling me that if we manually include the SLF4J API and a default Binding implementation that does the logic I desire, that we don't have to worry about classloading issues at all? What if our default Binding implementation is utilized by SLF4J before the user-configured binding is utilized? All binding implementations are the exact same package and class name: org.slf4j.impl.StaticLoggerBinder. For example, the org.slf4j.impl.StaticLoggerBinder implementation inside the slf4j-log4j12.jar uses the Log4J 1.2 API. The identically packaged-and-named org.slf4j.impl.StaticLoggerBinder implementation inside slf4j-jdk14.jar uses the JUL API. If we have our own org.slf4j.impl.StaticLoggerBinder that implements my desired logic, are we sure this won't override a user-configured SLF4J binding?
