On Jul 13, 2008, at 8:37 AM, Peter Ledbrook wrote:
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 :)
Years of thought and experience went into the SLF4J API. Frankly,
it's crazy simple. No matter what gets cooked up for the proposed
JSecurity logging facade, SLF4J API already does it and, since many,
many, other projects use it, the SLF4J API will be easier to grasp by
new community members and users.
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.
Yes, that's always an option. Many projects create "uber" jars to
make things easier for the grad students and other novices to use,
e.g. spring. It has always been my experience that once their gasp of
the material matures they always cast off the training wheels a exert
a finer degree of explicit control.
Regards,
Alan
