It's too late for me to have the time to respond with the same length that you used =) But I still think it's silly to implement our own logging abstraction layer. Name one popular open source project that does this. I can think of a couple that used to do that and have switched over to using a standard logging framework just like everyone else.
On Fri, 11 Jul 2008 00:28:49 -0400, "Les Hazlewood" <[EMAIL PROTECTED]> said: > 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? > >
