> I just realized that this change now requires _two_ additional Jars on > top of jsecurity.jar: slf4j-api.jar and one of slf4j's bindings > (slf4j-log4j12.jar, slf4j-jdk14.jar, etc.). > > This had the exact _opposite_ effect of my biggest desire - to > _reduce_ the number of required .jars
This does seem to be a downside of embedding the SLF4J api into JSecurity: you would still need one of the binding JARs. Because it uses static binding, you can't simply provide a default implementation and then override it with another. That said, SLF4J uses static binding partly to avoid class loader issues, so I'm slightly worried that a JSecurity logging facade may end up with similar problems to Commons Logging. Saying "it's really simple" and "it's already done" always gives me second thoughts - I've seen way too many problems with code that was supposed to be really simple :) At the risk of confusing users with the number of different JSecurity JAR files they can use, how about a jsecurity-nodeps.jar that basically incorporates slf4j-api.jar and slf4j-jdk14.jar? I'm not sure it's worth it, but it's an option. Cheers, Peter
