Why would you or anyone else on this list care if it might be over-engineering, especially when I've been able to whittle away to a minimalist solution with NO CL issues with an end result that will require extremely little or more likely NO maintenance?
I am extremely passionate about software engineering principals driving this issue - I could care less if it was logging or caching or any other API - the SLF4J case here is completely arbitrary as far as I'm concerned. That we would be 100% independent from any 3rd party API is beautiful design, plain and simple. That people want to shy away from it because it _might_ (and that is a big might), cause them to answer some user questions in the future is absolute garbage to me. Its like selling out on good design principals. It is being lazy as far as I'm concerned. A huge reason why I'm involved in JSecurity and OS in general is because I _can_ implement things in the cleanest possible way, they way they should be done - the way software fundamentals should be employed. I do it because these principals are not always possible in the commercial world, where schedules and costs often dictate (crap) results. This project is my breath of fresh air. My reduced solution works, it enables a cleaner, more flexible deployment scenario than using SLF4J natively, and there are no CL issues. There is nothing to learn. Its just an elegant solution. Why some feel it is not worth trying before 1.0 status just baffles me. On Tue, Jul 15, 2008 at 12:24 PM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > On Tue, Jul 15, 2008 at 4:13 PM, Jeremy Haile <[EMAIL PROTECTED]> wrote: >> So - all of this obfuscation, unnecessary abstraction, and additional >> classes is so that: >> >> a) users who already use SLF4J are unaffected. (their experience is neither >> IMPROVED or made worse) >> b) users who use commons-logging will be confused why JSecurity isn't >> logging correctly (since it will silently log to JDK 4 logger instead of >> failing due to the lack of an slf4j.jar) >> c) users who use JDK 1.3 will be really confused because they will get >> absolutely NO OUTPUT if they don't have slf4j in the classpath. >> d) users who use log4j directly will be confused per (b) or (c) based on >> whether or not they are running JDK 1.3 or JDK 1.4 and above >> >> My opinion is that it's better to force the user to include SLF4J. That way >> you avoid all of these confusing situations, you keep the code simple, you >> use a logging framework OS developers are used to, and you avoid having one >> logging abstraction built on top of another. >> >> And no - writing things out to stdout or stderr will not address my >> concerns. >> >> Still +1 for just using SLF4J. > > Agreed, I think this is still over-designing out ways out of a non-issue. > > /niklas >
