This entire issue is (for me) ultimately about perception: - "I only need jsecurity.jar? Awesome! This is so much easier to enable than most frameworks out there!".
- "Wow, only one jar - that's really easy for me to get approved by my company software standards body. But if I have to get 4 or 5 dependencies approved? That's a pain - Oh well, I guess I won't use JSecurity then..." Insane simplicity, beyond what the majority of other OS frameworks offer, has always been of utmost importance in our framework. I've said it many times before, and I'll say it many times again: If there is an added burden on the development team to jump through hoops because it will make lives easier for our users, it is almost always worth that burden. We exist to make lives as easy as humanly possible for people. On Fri, Jul 11, 2008 at 4:35 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Les Hazlewood wrote: >> >> Damnit! >> >> 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 >> >> :( >> > > OTOH, it bring the flexibility your users want. Are they using Log4j ? np at > all. The very same for JUL. > > I don't see what's wrong with this. Again, if JSecurity is meant to be used > in some complex applications, I don't see how problematic it is to carry 2 > jars when the applications themselves will carry possibly hundreds ! > > There is no silver bullet... Sorry that Sun messed it up with JUL, but this > is something we have to live with (even if nobody is using JUL ...) > > And your thin layer won't solve this problem in any way. If I'm a user, > writing my own application and using log4j, I really want all the logs for > all the libs I'm using to be configured through a single configuration file. > This is way more important than having to deal with two jars I will almost > anyway have in some of my pom.xml/build.xml. > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
