This is my ultimate goal: - jsecurity.jar deployed with nothing else. It works. - jsecurity.jar deployed with slf4j-api.jar and a binding .jar. It uses SLF4J and still works.
So yes, the current substitution does not improve the situation of achieving my goal because SLF4J is still a forced dependency. Those in disagreement with me believe that this is not a worthwhile goal given the maintenance it might require on the development team. On Wed, Jul 16, 2008 at 2:47 PM, Craig L Russell <[EMAIL PROTECTED]> wrote: > Mentor hat off. Architect hat on. > > I understand that the original goal was to remove the hard dependency on > commons-logging from the jsecurity code. > > I don't understand how substituting a hard dependency on another logging > framework improves the situation. > > Hats restored. > > Craig > > > On Jul 15, 2008, at 2:29 PM, Emmanuel Lecharny wrote: > > Niklas Gustavsson wrote: >> >>> On Tue, Jul 15, 2008 at 4:13 PM, Jeremy Haile <[EMAIL PROTECTED]> >>> wrote: >>> >>> So - all of this obfuscation, unnecessary abstraction, and additional >>>> classes is so that: >>>> >>>> a) users who already use SLF4J are unaffected. (their experience is >>>> neither >>>> IMPROVED or made worse) >>>> b) users who use commons-logging will be confused why JSecurity isn't >>>> logging correctly (since it will silently log to JDK 4 logger instead of >>>> failing due to the lack of an slf4j.jar) >>>> c) users who use JDK 1.3 will be really confused because they will get >>>> absolutely NO OUTPUT if they don't have slf4j in the classpath. >>>> d) users who use log4j directly will be confused per (b) or (c) based on >>>> whether or not they are running JDK 1.3 or JDK 1.4 and above >>>> >>>> My opinion is that it's better to force the user to include SLF4J. That >>>> way >>>> you avoid all of these confusing situations, you keep the code simple, >>>> you >>>> use a logging framework OS developers are used to, and you avoid having >>>> one >>>> logging abstraction built on top of another. >>>> >>>> And no - writing things out to stdout or stderr will not address my >>>> concerns. >>>> >>>> Still +1 for just using SLF4J. >>>> >>>> >>> Agreed, I think this is still over-designing out ways out of a non-issue. >>> >>> /niklas >>> >>> >>> +1. >> >> -- >> -- >> cordialement, regards, >> Emmanuel Lécharny >> www.iktek.com >> directory.apache.org >> >> >> > Craig L Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > >
