At the risk of sounding like an ass, wouldn't our collective energies be better spent on discussing and developing features and functionality more relevant to the true purpose of the framework, security. Logging is important and while our current implementation may not be perfect I would rank changing it very low on the priority list.
Perhaps I have very little room to criticize given my commit history but I just don't see a compelling reason to get wrapped around the axel on this one. I say leave it as is or go with SLF4J anything else seems like time not well spent. 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... > > > > 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 >> > >
