Two separate goals have been discussed:
1) One goal was to move away from commons-logging due to its well
documented class loader issues to SLF4J, which seems to be where the
OS community is heading. Moving to SLF4J from JCL would solve this
goal, and we have "I think" achieved consensus on this solution on the
mailing list.
2) The other goal was to make it so that certain users could deploy
JSecurity without hard dependencies on any external libraries,
including a logging framework. We have not achieved consensus on how
to solve this goal. We've mostly been debating between offering a
separate jar that bundles in a logging implementation or having a JAR
that wraps all logging in JSecurity code that makes JSecurity work
even if the logging JAR files aren't present.
On Jul 16, 2008, at 2:47 PM, Craig L Russell wrote:
Mentor hat off. Architect hat on.
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.
Hats restored.
Craig
On Jul 15, 2008, at 2:29 PM, Emmanuel Lecharny wrote:
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:
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
+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!
