For the continued purpose of this discussion, I've made my final changes to org.jsecurity.logging.*. I've tested in my local environment (where all files that reference a log use these classes - took a 5 minute search-and-replace), and it works perfectly. It is simplified even more. See below for my responses.
On Mon, Jul 14, 2008 at 12:05 PM, Alan D. Cabrera <[EMAIL PROTECTED]> 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? :) Yes, that is exactly it - unnecessary tight coupling to a 3rd party API. That is sure a compelling argument to me - that's just good architecture, even if you might disagree. My goal is to not _require_ a 3rd party dependency, especially if the integration effort to do so is as trivial as a 5 minute search-and-replace. >> 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. It is a problem *if* you don't want a forced dependency. Therefore it is a problem I would *like* to solve. > >> 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. I've already stated this won't happen - it will work fine if SLF4J is not included. Therefore there wouldn't be anything "missing". It becomes an optional feature at that point - add it if you want fine grained control. > 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. This is where I believe you're mistaken. I know our current end-user community better than anyone on this list. There has been an overwhelming feedback from users - many of whom are brand new to Java, let alone web applications, that rave about the simplicity of our framework and how easy it is to set up. The big mantra of this project is "we make life easy for you whenever possible, but make it flexible when you need it". This is NOT a low-level framework for those well-versed in Java. It is a framework for pretty much any skill level. > >> 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. That doesn't mean its not worth having. Again, my solution does not preclude what you explain. If they want to use SLF4J, they can do so at the time of their choosing. > > 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. This is not the case. My final incarnation of what I describe comes down to this: 2 interfaces, 7 classes, for both API _and_ implementation. And each implementation method is literally one line of code. It couldn't be simpler. >>> 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. Your definition of "needed" is what I disagree with. I feel clean loose-coupling of 3rd-party APIs is "needed" more so than tight coupling. There are a *LOT* of things in JSecurity that aren't "needed" for functionality but exist to make the lives of our end-user community much easier. And people love that. It is a common theme in our framework, and this is no different than our Caching layer or similar constructs. >> 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. Yes, it is not a show stopper, but I never claimed it to be. They are however, IMO very desirable to have in a ubiquitous security framework. > > I would reverse this argument and ask you to try what clearly the > overwhelming majority of the community wishes and use the SFL4J API. An overwhelming majority implies greater than a simple majority of 50%, which is not the case here. Jeremy, you, and Emmanuel are clearly against it. I and maybe Allan and at least Tim are at least willing to try it. 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". On that happy day when the community is up in arms and are clamoring to remove the abstraction layer, you can always tell us "I told you so". That works both ways :) Cheers, Les
