Re: SLF4J integration

[Craig L Russell]

Mentor hat off. Architect hat on.






Hats restored.

Craig

On Jul 15, 2008, at 2:29 PM, Emmanuel Lecharny wrote:

I understand that the original goal was to remove the hard dependency on commons-logging from the jsecurity code. I don't understand how substituting a hard dependency on another logging framework improves the situation.

Niklas Gustavsson 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:


IMPROVED or made worse)

failing due to the lack of an slf4j.jar)

absolutely NO OUTPUT if they don't have slf4j in the classpath.

whether or not they are running JDK 1.3 or JDK 1.4 and above


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.

a) users who already use SLF4J are unaffected. (their experience is neither 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 c) users who use JDK 1.3 will be really confused because they will get d) users who use log4j directly will be confused per (b) or (c) based on 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

/niklas

Agreed, I think this is still over-designing out ways out of a non- issue.

+1.

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature