I can't possibly see how this is not a good idea to incorporate. I can't see how the architects in you all don't see this as just "making sense". Low coupling, high cohesion, etc:
1. There will be _NO_ changes to existing or future deployments that want to use Apache Commons Logging or SLF4J. Zero. Period. 2. There will be _NO_ configuration requirements required to support this. 3. This eliminates any _required_ dependencies. Very convenient for a minimalistic deployment, and convenient for the security-conscious. 4. This is so trivial that it took me 30 minutes to implement. There's no "wasted effort" or a "waste of time". This is an OS framework, and if I want to waste my time to support an end user when that feature only benefits our framework, and doesn't hurt it in any manner, I feel like that's a good choice. 5. There is _NO_ burden on existing or future JSecurity users or developers. The only requirement is to use this: Log log = JSecurityLogFactory.getLog( getClass().getName() ); instead of Log log = LogFactory.getLog( getClass() ); Is that so much to ask? Especially when we get all the benefits that I've outlined? On Fri, Jul 11, 2008 at 10:46 AM, Jeremy Haile <[EMAIL PROTECTED]> wrote: > To me this is classic over-engineering. Why are we writing a custom logging > abstraction layer because one user complained? Ridiculous! > > If I build the trunk now, is there even SLF4J, commons-logging, or log4j > support? My current application at work is running off of trunk code for > testing, so if I built now it seems I'd be without good logging support. > > Given all of the security-related things that we need to be working on in > JSecurity, all of the unit tests we need to write, and all of the > documentation that needs to be written - I feel like any effort to change > out a logging framework and all the discussion around it is a complete waste > of time. > > > > On Jul 11, 2008, at 10:40 AM, Tim Veil wrote: > >> 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 >>>> >>> >>> > >
