Yes, that's very true - how easy the API is to understand and how easy it is to configure. The configuration problems have mostly been solved now, so we should be smooth sailing from now on.
It was just my dream to have it be even easier. That I had a solution to make it even easier (that worked!), but it is not agreed upon, is where I was rather disheartened. Its not like I was asking anyone to actually do any work, God forbid ;) On Fri, Jul 11, 2008 at 4:59 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > IMHO, JSecurity perception will almost only depends on the API it offers, > and how easy it will be to configure. > > Dependencies handling is a one time hassle. Really, when you are considering > using an external library, what are you looking at first ? The number of > jars it depends on ? Come on ... This is the last thing you will look at, > unless it really conflicts with the jars you are already using, which is not > something which will happens with slf4j, as it handles all the different > cases (except the companies who have developped their very own Log lib, > because they were hit by a big NIH syndrom ... I already met this kind of > case in real life : a pathetic failure !) > > Les Hazlewood wrote: >> >> 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 >>> >>> >>> >>> > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
