Les Hazlewood wrote:
I can't possibly see how this is not a good idea to incorporate. I
can't see how the architects in you all don't see this as just "making
sense". Low coupling, high cohesion, etc:
1. There will be _NO_ changes to existing or future deployments that
want to use Apache Commons Logging or SLF4J. Zero. Period.
2. There will be _NO_ configuration requirements required to support this.
3. This eliminates any _required_ dependencies. Very convenient for
a minimalistic deployment, and convenient for the security-conscious.
4. This is so trivial that it took me 30 minutes to implement.
There's no "wasted effort" or a "waste of time". This is an OS
framework, and if I want to waste my time to support an end user when
that feature only benefits our framework, and doesn't hurt it in any
manner, I feel like that's a good choice.
5. There is _NO_ burden on existing or future JSecurity users or
developers. The only requirement is to use this:
Log log = JSecurityLogFactory.getLog( getClass().getName() );
instead of
Log log = LogFactory.getLog( getClass() );
Is that so much to ask? Especially when we get all the benefits that
I've outlined?
As I already said, we went through this whole discussion over the years
and over many projects. Always the same story... From experience, this
is more code to maintain, more problem likely to occurs in the future,
and more important, hours of painfull and useless discussion about pros
and cons on matters already debated on other projects.
I just give you some insight about what we went through in the past,
just to try not to get trapped again in such a discussion.
At the end, if it's controversial, a vote can help...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org