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
