But we're not using commons-caching and there's not really a well
accepted standard abstraction for caching, like there is for logging.
One level of abstraction on top of an API is fine, but two seems
unnecessary. Other libraries that used to provide their own logging
abstractions (back when that was normal in the 90s) are migrating away
from that to commons-logging and now SLF4J. If a user wants to
implement their own logging implementation (why in the heck would they
do that?) they can just integrate with SLF4J and commons-logging,
since those ARE abstractions.
On Jul 10, 2008, at 3:50 PM, Allan Ditzel wrote:
This sounds like a good idea to me. As you said, doing something
like this
for caching has given us a fair amount of flexibility with no negative
side-effects. My vote is yes.
On Thu, Jul 10, 2008 at 3:46 PM, Les Hazlewood <[EMAIL PROTECTED]>
wrote:
http://issues.jsecurity.org/browse/JSEC-117
On Thu, Jul 10, 2008 at 3:37 PM, Les Hazlewood <[EMAIL PROTECTED]>
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?
