> The most important implementation is JSecurityLogFactory - please look > at the source code and you'll see how I do my graceful degredation > check. That is really all there is to it, plus the one-liner methods > of the respective Log implementations.
This is what worries me. While eliminating dependencies on third-party libraries is a worthy goal, the current implementation does not appear to be devoid of potential class loader issues. In particular, I'm not sure that slf4j-api.jar will be found if it is loaded by the same classloader as jsecurity.jar, but not the context class loader or system class loader. Gracefully degrading to JDK logging while SLF4J is on the classpath somewhere isn't particularly helpful. To be honest, I don't fully understand the class loading issues, but I do know that JCL still has not resolved the problems despite knowing about them. I also know that SLF4J eschews runtime resolution of loggers. Are you really that sure that the JSecurity implementation is not going to have problems? The biggest issue for me is that class loader issues are *really* difficult to diagnose, so if people have issues 6 months down the line, we'll probably decide it's a configuration error on their part. That's if they report them rather than simply dumping JSecurity. Cheers, Peter
