I just like my fresh air. I don't wanna breathe smog here, when I have to do it at work already :)
On Tue, Jul 15, 2008 at 12:46 PM, Tim Veil <[EMAIL PROTECTED]> wrote: > easy there big fella > > On Tue, Jul 15, 2008 at 12:39 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > >> 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 >> > >> >
