I don't see what's so great about being free of a logging abstraction
API when our API does tons of logging. Using commons-logging or SLF4J
is a ubiquitous standard in the OS community. It allows users to
plugin whatever logging solution they want to use and have it work
across all of the libraries and services that they depend on (such as
JSecurity).
To me, removing this dependency just creates more confusion and
obfuscation around the right way to set things up for users - and for
developers it creates more confusion because they aren't using a
logging API that they're used to using. In reality, users *should*
use an underlying logging framework - so allowing JSecurity to work
without one just makes it a) easy to set things up badly and b) adds
confusion around what a user should do to set things up "right".
I guess there's a tradeoff in this architecture ideal you have of
"zero dependencies" vs simplicity and standardization. I'd rather go
with the simpler, more standard approach that most users and
developers understand already. Especially since the "zero
dependencies" ideal is driven by pure "academic" desire, rather than a
widespread need across the community.
Jeremy
On Jul 15, 2008, at 12:39 PM, Les Hazlewood 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
