On Fri, Jul 11, 2008 at 10:28 AM, Jeremy Haile <[EMAIL PROTECTED]> wrote: > So, how exactly are you proposing I use SLF4J with the new code you checked > in? I don't see any support for it... > > It sounds like you are talking about doing detection of whether or not the > jar is in the classpath - which would result in the same classloading > hassles that is making everyone switch away from commons-logging to slf4j. > If we followed slf4js approach, then everyone would have to include > jsecurity-slf4j.jar in their classpath, plus slf4j.jar plus slf4j-log4j.jar. > This seems like a needless hassle. > > My vote would be to stick with slf4j for now... It seems like most voices > on the mailing list are saying this, yet the change has already been > committed. Not very meritocratic...
You must not have read my email. I explicitly said the change was committed BEFORE I received any feedback at all due to mailing list problems. Plus having it in the repository is easy for you guys to look at. I also wrote that I would delete it if we felt like it wasn't a good idea. You must not have read that either. :/ > > > On Jul 11, 2008, at 10:09 AM, Les Hazlewood wrote: > >> On Fri, Jul 11, 2008 at 2:54 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> >> wrote: >>> >>> Les Hazlewood wrote: >>>> >>>> Reason 1: What happens when the latest-n-greatest new logging >>>> framework comes out in 2 years from now? Will we refactor again? >>> >>> This is a possibility :) We don't live in a frozen world ... >> >> True, but the concept of low coupling and high cohesion and >> independence from 3rd party APIs is always a *good thing*. There's no >> reason not to utilize it if it does not introduce noticeable >> complexity and works in all current cases. My solution achieves both >> of these. >> >>>> >>>> I >>>> suppose we could, but, why not just eliminate that possibility? >>> >>> Well, it's not likely that our own logging system will also remain >>> unchanged for years. >> >> The point is that _we_ would control the change when we feel it might >> be necessary. This goes back to the low coupling argument. >> >>>> >>>> Or >>>> what if there is some flaw in SLF4J that makes it undesirable, much as >>>> happened to Commons Logging (I've seen the CL problems myself - they >>>> are real, even if they are rare). >>> >>> Then we switch to the 'next best framework'. So far, and it's now 2 >>> years slf4j exists, it's pretty stable. And Slf4j has been designed to >>> avoid the problems CL had. >> >> I think you're slightly misunderstanding my proposal. SLF4J is still >> my preferred logging framework. I don't want to write another one - >> I'm only talking about a very thin wrapper, which in most cases, the >> default implementation used will be SLF4J. >> >>>> >>>> Our own lightweight wrapper API >>>> makes JSecurity more resilient. >>>> >>> >>> You will face users questions like : "why do I have to configure the >>> logger >>> in some way which is incompatible with the logger I already use?" ad >>> nauseam. >> >> Nope, we won't experience this. I'm not writing another logger >> subsystem. They use the one they already have, and there is no >> configuration necessary, unless they want to use something _other_ >> than SLF4J or Commons Logging or the ones those two support. My >> solution is absolutely 100% transparent to all existing users as well >> as users of all the other logging frameworks. >> >>>> >>>> Reason 3: I know you said something like "why would they even want to >>>> do that [implement their own logging framework]"? The sad reality is >>>> that there are many companies that have their own logging frameworks >>>> that are used across the organization that are NOT built upon standard >>>> OS frameworks like SLF4J or Commons Logging - they are proprietary, >>>> integrate with centralized monitoring servers, JMS, etc, etc. My >>>> current client is one such company. The people who contacted me >>>> yesterday are another company. Allan's current company is another >>>> such company. They exist in greater numbers than I'd like to see, but >>>> they're out there. >>>> >>> >>> Sure, but is this a reason because some companies (and as there are >>> millions >>> out there :) are >>> not using an existing framework to define a brand new logger system which >>> will not be able >>> to cover all the cases anyway ? >> >> Yes, that is the reason - but we don't have control over that. Most >> of them are legacy frameworks, and won't be changed for years. And if >> we're going to provide a ubiquitous security framework, we _should_ be >> able to play nice in those environments too. _Especially_ if what I'm >> talking about does not in any way affect current users or users of >> Commons Logging or SLF4J. Its 100% transparent. >>> >>>> Reason 4: our own trivial wrapper API prevents us from a forced >>>> runtime dependency on another library. This caters to: >>>> >>>> a) deployment simplicity - just drop jsecurity.jar into the classpath >>>> and you're done. Add more jars if you want customized features. >>>> b) lightweight environments. People can use JSecurity in any java >>>> environment, from web apps to cell phones, without worrying about >>>> requiring an extra 50k to few megs of dependencies. This better >>>> enables JSecurity as being known as a truly ubiquitous security >>>> framework. >>>> c) controlled environments - that a security framework does not >>>> require other frameworks is a piece of mind security-conscientious >>>> users and software standards groups will appreciate >>> >>> This is an interesting point which may deserve another thread. >>> At some point, if JSecurity is to be a standalone lib, that mean many >>> libs won't be used (commons-xxx, and such), and it may be a real burden, >>> or at least a real cost. What libs are currently used in JSecurity ? >> >> The current required libraries are commons-logging.jar, and if you use >> our text-based configuration (as most people do), Commons Bean Utils. >> But the only absolute requirement is commons-logging.jar. If my >> proposition is incorporated, commons logging and SLF4J can still be >> used, but they are not mandatory. >> >>>> >>>> Reason 5: this is a feature desired by an actual end-user - not >>>> something I'm just dreaming up or over-engineering. This means there >>>> is desire from an end-user that is representative of other companies >>>> out there that might use JSecurity as well. If we do this now, we >>>> don't have to worry about similar requests later (as Emmanuel pointed >>>> out happens from time to time) as JSecurity becomes more heavily >>>> adopted outside of just web applications. >>>> >>> >>> It depends. The problem is that if you have 100 companies using >>> JSecurity, 99 using Log4j and 1 using another system, you will hear >>> from the one company having problem with JSecurity, and not about the >>> 99 others. If you switch, this is very likely that you will start having >>> some of the 99 companies complaining :) >> >> Again, this will not happen. My solution is totally transparent, but >> has the added benefit of supporting more use cases. >> >> Cheers, >> >> Les > >
