It sounds as if 3 people on this list just want this issue to go away. If that is so important to you, just let me do my 5 minute change that is guaranteed to work, and I'll be quiet immediately. :)
I've guaranteed that SLF4J is the preferred mechanism for abstracting any other 3rd party implementation. My solution requires no 3rd party dependencies. It doesn't get in your way, and after it is enabled, everyone will probably just forget about it. It enables desirable behavior, but disables or prevents nothing. It doesn't even require work or maintenance. Surely you can see the logic of why this isn't a bad thing! On Mon, Jul 14, 2008 at 12:52 PM, Tim Veil <[EMAIL PROTECTED]> wrote: > +1 > > On Mon, Jul 14, 2008 at 12:50 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> > wrote: > >> I totally +1 what Alan said. >> >> Can we move on and let this thread behind us, so that the project does not >> stay 3 years in incubation, because of endless arguments ? >> >> >> Alan D. Cabrera wrote: >> >>> >>> On Jul 14, 2008, at 7:00 AM, Les Hazlewood wrote: >>> >>> Yet again, I'm NOT writing a proper abstraction layer to handle any >>>> underlying implementation. >>>> >>> >>> But everyone else says you are writing an abstraction layer. I prefer to >>> call a rose a rose. Call it what you want and we shall agree to disagree. >>> >>> On Mon, Jul 14, 2008 at 9:04 AM, Jeremy Haile <[EMAIL PROTECTED]> >>>> wrote: >>>> >>>>> I don't think we should try it. I think we should drop it. I can't >>>>> figure >>>>> out why we are still arguing about this. Like Alan just said - what >>>>> problem >>>>> are we trying to solve? >>>>> >>>> >>>> For the like 12th time, this is the problem I'm trying to solve: >>>> >>> >>> I have answered all these issues in previous posts with compelling >>> arguments that have gone unanswered. >>> >>> 1. Proper low coupling/high cohesion with all aspects of our API, >>>> logging included. >>>> >>> >>> Not a problem but a goal and one that the SLF4J API provides already. You >>> have not yet provided a compelling argument as to why the SLF4J API does not >>> provide this. Could it be that it doesn't have org.apache.jsecurity as a >>> starting package name? :) >>> >>> 2. Use SLF4J as the primary logging mechanism if it is in the classpath. >>>> >>> >>> Not really a problem to be solved. You are merely restating how your >>> logging mechanism would work. >>> >>> 3. Graceful Degredation if SLF4J is not in the classpath. Note that >>>> my solution for checking if it is in the classpath will NOT result in >>>> the class loader issues that Commons Logging has. This is possible >>>> due to #1. >>>> >>> >>> A tenuous use case at best and will only happen to the grad student first >>> using the product. The *last* thing we want to happen is for a user to >>> think that he has everything buttoned down when in fact he was missing a >>> dependency and we were hiding that fact from him. >>> >>> Let's keep in mind what we are building. This is not something to help my >>> dad's office assistant make a web site to post pictures of his kids. It's a >>> security framework. People arrive at this this task with girded loins. The >>> LAST thing you want is automagical things going on behind the scenes, >>> especially when it comes to security. >>> >>> 4. No _forced_ dependencies. This is possible due to #1. >>>> >>> >>> We talked about this many times before and I had looked forward to your >>> comments. I will repeat my points here. >>> >>> Many projects create "uber" jars, which minimize dependencies, 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. >>> >>> The specter of a SLF4J API dependency is moot when one realizes that it's >>> just the tiny API jar. >>> >>> JSecurity Logging API == SLF4J Logging API >>> >>> functionality wise, size wise, and class number wise. The community will >>> require that and will not accept a dummied down API. With that said, what's >>> the point in re-inventing a logging API that people who have years of >>> experience in that field have already come up with? >>> >>> Given the above points then the two are roughly equal functionality wise, >>> size wise, and class number wise and the argument about coupling 3rd party >>> dependencies in this case is moot. >>> >>> There's no reason to add additional code and complexity if there aren't >>>>> problems to be solved. (that can't better be solved by just using SLF4J >>>>> - an >>>>> established solution) >>>>> >>>> >>>> There's nothing wrong with it if the code is so trivial that a monkey >>>> could understand it. I'm not asking anyone to do ANY effort. I'm not >>>> asking anyone to maintain it. I've even said that if we actually have >>>> a problem with it - that is, something _actually_ comes up _in >>>> practice_ that indicates it is not working as expected, that I'll do >>>> the 5 minute code change it takes to force the SLF4J dependency. >>>> >>> >>> Here you are dead wrong. The community is against ad hoc inclusions of >>> code that is not needed, regardless if someone else is doing the work. >>> >>> You have nothing to lose. You have the above 4 points to gain. That >>>> no one here has to lift a finger and won't affect their coding at all >>>> and _still_ I'm getting pushback is driving me nuts. Just try it for >>>> Pete's sake. Then we can move on and no one here will ever have to >>>> worry about this again. >>>> >>> >>> Half of your points are not problems at all. The other half are, at best, >>> conveniences not show stopper problems that need to be solved. >>> >>> I would reverse this argument and ask you to try what clearly the >>> overwhelming majority of the community wishes and use the SFL4J API. On >>> that happy day when the community is up in arms and are clamoring for >>> another abstraction logging layer on top of an abstraction logging layer on >>> top of a logging layer, you can always tell us "I told you so". >>> >>> >>> Regards, >>> Alan >>> >>> >>> >>> >>> >>> >> >> -- >> -- >> cordialement, regards, >> Emmanuel Lécharny >> www.iktek.com >> directory.apache.org >> >> >> >
