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.
Jeremy
On Jul 15, 2008, at 10:02 AM, Les Hazlewood wrote:
That is, the following:
//SL4J native API
Logger log = LoggerFactory.getLogger(getClass());
is functionally identical to this:
//JSecurity wrapper API:
Log log = JSecurityLogFactory.getLog(getClass());
_if_ SLF4J is anywhere the classpath. If not, there is graceful
degredation. This solution does not use reflection.
On Tue, Jul 15, 2008 at 10:00 AM, Les Hazlewood <[EMAIL PROTECTED]>
wrote:
Ok, I committed a solution that will definitely work with NO class
loader issues.
It uses static linking just like SLF4J. Now there should be no more
arguments against this solution due to potential CL issues - they
can't occur now.
Please do an SVN update and look at JSecurityLogFactory again. I've
tested this and works well.
