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 ofCommons 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) Loginterface that we would use in our classes instead of Commons Logging. Hebrought 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 forany environment. We already do the same thing for caching (Cache,CacheManager) which in turn delegates to Caching product implementationspecific 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 ourfavorite infrastructure. Any thoughts or objections?
I'm no expert, but I agree that removing third party dependencies from a core technology like security has to be a strong benefit.
Craig Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
