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
