Since I missed Emmanuel's and Jeremy's previous responses, I'll quote them here and respond:
Emmanual said: "This is typically the kind of proposal we always go through. Some peeps ask us to implement another layer on top of logger layers. They think it will fix some kind of CL problem. We should resist as much as possible. The reason it's really not a good idea is that those proposals are driven by people who are using a specific logger and don't want to deal with another one, or at least, don't understand how it should be done the right way." Jeremy said: "I'd rather not use another level of logging abstraction - just seems like overkill to me. Swapping out different logging frameworks is typically just a matter of search/replace. And the whole point of SLF4J and commons-logging IS to be the level of abstraction that allows you to swap out log implementations. So why add another on top?" Reason 1: What happens when the latest-n-greatest new logging framework comes out in 2 years from now? Will we refactor again? I suppose we could, but, why not just eliminate that possibility? 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). Our own lightweight wrapper API makes JSecurity more resilient. Reason 2: Writing an SLF4J implementation is not as easy as it sounds - you have to worry about Marker objects and child Markers, which isn't trivial. So, it can be more work than is worth it or needed just to support your proprietary logging environment. 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. 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 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. At the end of the day, in principle, this is no different than the concept of our thin Cache API wrapper interfaces. There is a (mostly) standard JSR specification, JCache, that I could have used, but we didn't know if it was going to change and frankly, required implementing more things than necessary for our framework - so I created our own wrapper API. Now we can alter our API when our framework mandates it, not because of changing specs or new projects/products. It adheres to the principals of loose coupling, exactly as this thin Logging wrapper API would. This makes good architectural sense. So, if you consider the sub points of Reason 4, I've given 8 reasons of why this is a good idea. The only contrarian reason that I've heard thus far (I think) is that it might not be worth the effort. In my opinion, it is a trivial effort, given the benefits provided. So, as a matter of testing this, I implemented such a thin wrapper API already, even before I received the responses to this thread - I was just playing around and wanted to see what it might be like. I did so in no way thinking that it would be the final solution - I was just playing around as if in a sandbox, awaiting everyone's feedback. I didn't hear any feedback for hours, so I thought I would commit these new components to the repository so you all could see what they looked like and reference them in the context of this thread. Again, I did this _before_ I heard any feedback at all - because I wasn't receiving messages on this list, I proceeded as a result of what I perceived as radio silence. I will gladly delete them from the repository if the team feels they are a bad thing. Realize this took me all of maybe 30 minutes this afternoon for a fully functional implementation, so the 'effort' argument is a moot point. So, please do an SVN update and look at org.jsecurity.logging.*. The interfaces/classes are there, but not integrated into any of our classes. They are essentially orphans at the moment. But, if we wanted to use it, the ONLY change required to get this into place and functional would be to search-and-replace all of these lines: protected transient final Log log = LogFactory.getLog( getClass() ); with this: protected transient Log log = JSecurityLogFactory.getLog( getClass().getName() ); with the corresponding import adjustments. That's it. All Log usages and method signatures remain the same. So, please look at it, see what you think, and if you can provided reasonable counter arguments to the 8 reasons above, (and remembering that the work is already complete), I will gladly delete them. If not, I'd like to call a vote to keep them in. Thanks for your consideration, Les On Thu, Jul 10, 2008 at 3:37 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > Hi all, > > I was contacted via private email yesterday about a company that wishes to > use JSecurity in their product, but they were concerned about our use of > Commons Logging, citing the now familiar classloader issues. It was > interesting timing because of my proposal to use SLF4J last week. > > This gent's recommendation was that we have our own (very minimal) Log > interface that we would use in our classes instead of Commons Logging. He > brought up a number of cases of difficulty implementing frameworks in > companies that have their own proprietary logging framework (events, > monitoring, etc), and said it would be much easier and more flexible if they > could implement their own version of a Log interface to do what they need, > using their companies' APIs. > > I think it is a good idea, and would be super easy - it is basically one > interface (Log) and maybe a 2nd (LogFactory, whatever). Then our default > implementation could use the JVM logger or SLF4J to allow any number of > pluggable logging implementations. This provides greater flexibility for > any environment. We already do the same thing for caching (Cache, > CacheManager) which in turn delegates to Caching product implementation > specific classes (ehcache, JCache, etc). Same concept. > > The thing that sounds clean to me about this, is that if it was implemented, > we would have NO required dependencies on any 3rd party library. That just > feels sexy. But we can still have default implementations that use our > favorite infrastructure. > > Any thoughts or objections? >
