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 > > >
