Good point. Perhaps there are good arguments that haven't already
been expressed ;-)
I do feel like we are spending undue amounts of time discussing a
logging implementation, rather than addressing the serious holes in
JSecurity's security implementation, unit tests, and documentation.
In my opinion, those are much more worthy of heated debate and much
more worthy of our time. Hence I think the faster we can get through
the logging issue and on to important issues, the better.
On Jul 11, 2008, at 12:15 PM, Alan D. Cabrera wrote:
SLF4J is broken up into small jars which separate the API from the
implementation; there are do nothing implementations. With that
said, if you implemented a "JSecurity logging API" with the same
functionality as SLF4J, from the logger's POV, then you will
basically end up w/ SLF4J.
By coming up with your own "JSecurity logging API" all you've done
is obfuscate the fact that you've added x amount of logging classes
into the JSecurity jar. Jar size will be about the same as if you
bundled the SLF4J api jar in w/ JSecurity.
Regards,
Alan
On Jul 11, 2008, at 9:03 AM, Les Hazlewood wrote:
If you use JSecurity in a cell phone, would you like it if you were
forced to incorporate a logging framework that you had no use for and
just wanted to use the phone's logging capabilities directly?
On Fri, Jul 11, 2008 at 12:01 PM, Jeremy Haile <[EMAIL PROTECTED]>
wrote:
On Jul 11, 2008, at 8:23 AM, Les Hazlewood wrote:
C'mon guys - I'm not asking you to do _anything_. There is
literally
NOTHING that you have to do. It already works! It enables more
end-users! Why on earth would you want to shut this down when
there
are _NO_ negative effects? I just don't get that. Just use it
and be
happy! Why can't you let me have this? :)
Why can't your contract pay you to implement an SLF4J -> Acme Co
logging
adapter? Seems like they would then get more bang for their buck
as it
would be applicable to other projects as well.
I agree - SLF4J and commons-logging ARE logging abstractions. We
don't need
a logging abstraction on top of a logging abstraction on top of a
logging
framework...
