Yep, there is a comment in the code, stating that is the expected condition:
//SLF4J not available or not initialized properly, try remaining possibilities That it still continues to work, even when they've misconfigured their end, means it is resilient to failure as a good security framework should be. SLF4J maintains the same philosophy - it will _never_ throw an exception if you've done something wrong or something internally goes wrong. Only the classloader will complain if you've forgot a binding. On Tue, Jul 15, 2008 at 4:34 PM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > On Tue, Jul 15, 2008 at 4:07 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> I can even simplify the solution even more by removing classes. I >> could get this solution to work with 1 Log interface, 1 LogFactory >> abstract class, and 3 Log implementations - Slf4JLog, JdkLog, NoOpLog, >> all methods 1 line each - easy peasy. >> >> That would be it - 5 files total. That would be as simple as it could >> get, again with no class loading issues. Wouldn't this be acceptable? > > Having some more time than for my last reply I went looking at the > current version in SVN. The current implementation will eat the > exception that SLF4J throws when only the API is present and not an > implementation. I'm guessing that's not the behavior you want since > the user in that case has gone through the trouble to set up the API > JAR but somehow missed out on the implementation. In that case, > JSecurityLogFactory would now silently ignore SLF4J completely and go > for JUL. > > /niklas >
