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