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
