Maybe you didn't read the email thoroughly: "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"
So there is no harm in going back to the way it was until a formal vote is actually called. On Thu, Jul 17, 2008 at 11:12 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > On Jul 17, 2008, at 7:48 AM, Les Hazlewood wrote: > > 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. >> > > > You do not get to decide. The community gets to decide. There was a > consensus and that was to use SLF4J. > > Were you able to file that Jira issue w/ infrastructure to move the SVN > repo? > > > Regards, > Alan > >
