I'd rather not use another level of logging abstraction - just seems
like overkill to me. Swapping out different logging frameworks is
typically just a matter of search/replace. And the whole point of
SLF4J and commons-logging IS to be the level of abstraction that
allows you to swap out log implementations. So why add another on top?
If someone wants to use SLF4J right now, they can simply use SLF4Js
bridging APIs that masquerade as commons-logging but under the hood
use SLF4J. Then when we migrate over to SLF4J, they can simply remove
the bridge jar files:
http://www.slf4j.org/legacy.html
On Jul 10, 2008, at 3: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?
