> I don't see any compelling need or demand to make this change. And I don't > believe that there won't be any problems. Once code is committed and used > by the project, it becomes the burden of the whole community to support and > maintain it. And frankly, I don't want to support a custom logging > abstraction framework. I'd rather use a tried and true one that is very > unlikely to cause any support or maintenance burden.
Everyone needs to get it out of your head that this is a full-blown logging abstraction framework or that it will need maintenance. We're not providing multiple implementations for Log4J or Logback, etc. Its just a graceful degredation and low-coupling mechanism. I've already made the promise that if we see even one user-reported problem due to how we use logging, then I'll eliminate it entirely via a 5-minute exercise. Also, this Logging API is considered Framework Internal - no one outside the JSec dev team should ever use these interfaces or implement their own. That is what SLF4J is for, _if_ they want to create a custom logging implementation. 95% of users (except big companies) will never even need to contemplate it.
