Because we have been unable to reach a consensus about exactly how to use SLF4J, and I need to focus on getting the release out so a few of us on the team can use it at our respective workplaces, and I just want to move on, I have reverted the code back to using JCL for all logging and committed it. I have also deleted my logging API entirely.
The code now functions exactly the way it has for 4 years, and we've never had any complaints about JCL from end-users or team devs until I surfaced SLF4J integration, so hopefully I won't hear any complaints about this. I would like to remind everyone that the consensus about SLF4J previously was that no one had a problem with me trying it out. There was no formal declaration or vote that "yes, the JSecurity project will use SLF4J for all logging". Here are my reasons for doing this: 1. We couldn't reach a consensus on how to use SLF4J. Going back to the way things have always worked when a consensus can't be reached is not harmful. 2. SLF4J does require more jars (2 as opposed to JCL's 1), being more of a configuration hassle. This is minor, but it is true nonetheless. 3. If we used slf4j-api.jar, it requires one or more bindings for the to incorporate. We don't include these in our project, so they'd have to go manually retrieve them from somewhere else. We could include all of the bindings in our project distribution, but that would bloat the project unnecessarily (6 or more binding jars? I can't remember...), and I'm not sure that's a good approach. 4. *If* people experience the rare CL issues from commons-logging, can just put in jcl-over-slfj4.jar in their classpath instead, no more CL issues. This is a deployment time decision that the end-user can make and not something we must force on them. 5. If we force slf4j, 2 different jsecurity-enabled applications in same JVM are forced to use the same logging infrastructure. We shouldn't force that condition on anyone if we can avoid it (which we can), but the end-user can enable it fine via #4 if want. 6. We have a dependency on commons-beanutils for text-based configuration, either standalone in jsecurity.ini or embedded in web.xml. These two configuration mechanisms constitute probably more than 90% of the way people configure JSecurity, so it is wide-reaching. Commons-beanutils has a dependency on JCL already, so those classes must be in the classpath. If we switch from JCL to slf4j-api.jar, then the user will be forced to configure a minimum of 5 jars to use jsecurity: jsecurity.jar, commons-beanutils.jar, slf4j-api.jar, jcl-over-slf4j.jar and one of the slf4j binding .jars, which again surfaces #3. Numbers 4 and 6 are deployment time considerations that should be determined entirely by the end-user based on their specific environment, not something we should force on them, especially when we don't have to. I will be happy to re-visit this issue if end-users start to complain about JCL or express a definite *need* for SLF4J, but until then, it is not worth arguing over any more. Les
