I'm scratching my head, wondering what's wrong with slf4j. Not sure
why this project would want to dummy down an already simple logging API.
Regards,
Alan
On Jul 10, 2008, at 12:37 PM, Les Hazlewood wrote:
Hi all,
I was contacted via private email yesterday about a company that
wishes to
use JSecurity in their product, but they were concerned about our
use of
Commons Logging, citing the now familiar classloader issues. It was
interesting timing because of my proposal to use SLF4J last week.
This gent's recommendation was that we have our own (very minimal) Log
interface that we would use in our classes instead of Commons
Logging. He
brought up a number of cases of difficulty implementing frameworks in
companies that have their own proprietary logging framework (events,
monitoring, etc), and said it would be much easier and more flexible
if they
could implement their own version of a Log interface to do what they
need,
using their companies' APIs.
I think it is a good idea, and would be super easy - it is basically
one
interface (Log) and maybe a 2nd (LogFactory, whatever). Then our
default
implementation could use the JVM logger or SLF4J to allow any number
of
pluggable logging implementations. This provides greater
flexibility for
any environment. We already do the same thing for caching (Cache,
CacheManager) which in turn delegates to Caching product
implementation
specific classes (ehcache, JCache, etc). Same concept.
The thing that sounds clean to me about this, is that if it was
implemented,
we would have NO required dependencies on any 3rd party library.
That just
feels sexy. But we can still have default implementations that use
our
favorite infrastructure.
Any thoughts or objections?
