I also wrote that the change is not incorporated to any of our existing components. It is essentially an API orphan at this point - just a place holder in case we used it.
On Fri, Jul 11, 2008 at 10:43 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > 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 >> >> >
