a) correct b) it would be a piece of cake to include a 4th Log class that wraps commons logging to support that case. We don't even need to use the commons-logging.jar and can just use the jcl-over-sl4j.jar for compiling our own project. 6 classes total is still pretty convenient. c) Info levels and above could go to System.out. This is exactly what SL4FJ does with the "Simple Logger". Or, we could not do that at all and just print to System.out when we first initialize that "Logging is disabled on 1.3 when SLF4J is not in the classpath." That's good enough message enough to let people know what to do. d) Not true if b) was implemented - if you use log4j directly, you know that pretty much every OS project requires a wrapper API. So, when they see that JSecurity fails, its because they haven't included the Commons Logging or SLF4J jars. This would happen without my solution as well, so it is a moot point.
"All of this obfuscation, unnecessary abstraction, and additional classes" - - Not much obfuscation - 1 interface. That's it: Log. - I find it necessary for a core security framework to NOT be dependent on 3rd parties if we can avoid it and the effort is simple. So I find it to be a necessary abstraction. - Addional classes - 6 classes. That's so tiny it is totally negligible. On Tue, Jul 15, 2008 at 10:13 AM, 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. > > 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. >>> > >
