+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 > > >
