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...
