Nicola Ken Barozzi <[EMAIL PROTECTED]> writes: > Jon Scott Stevens wrote: > > on 2002/12/10 11:51 PM, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: > > > > >>Avalon is a server framework. You mean that logging is not to be a > >>concern of a server framework? > > Correct. Very much so. If Avalon was a logging framework, then > > logging would > > > be a concern. But it isn't. > > Logging done in server apps is a *concern* of the server framework; > the logging policies are definately concerns of server apps, hence of > the frameworks to create them.
Logging is definitely a concern of server frameworks. However, it's not up to a framework to supply implementations for something which will have very different use cases depending upon a user's environment. In this case, both Commons Logging and Avalong supply a set of Java interfaces which allow (somewhat) pluggable logging. This confuses the issue, as both parties think that they're not supplying implementations. In fact, both are supplying implementations of a conceptual, meta logging interface (imagine a checkbox on a marketing hand-out, but don't be sidetracked by my reference to marketing ;). I'm always going to choose the tool which works best for the situation at hand. Now, I assume that both implementations of the conceptual logging interface _function_ just fine -- that's not what's under debate. What's under debate is why to choose an Avalon-specific implementation over a Commons implementation. As both implementations are roughly functionally equivalent, we need to look at their other attributes. The Avalon project is a server framework, not focussed on logging. The entire point of Commons is to develop very specific components shared as widely as possible -- its Logging component is focussed _specifically_ on logging. Unless there's some technical point which I've overlooked (please speak up if this is so), I'm going to choose the implementation with the narrowest focus every time. Generally speaking, a narrow focus means I can count on the tool to be highly cohesive, and over time much more widely deployed (for instance, Commons Loggin ships with Tomcat 4). The wide deployment means that more of my users are likely to have come in contact with the tool before, and may already be using it in their environment. This familiarity results in a lower learning curve when coming up to speed on my framework. I could go on about the "softer" aspects of tool choices for days, but I'm sure we all get the point. :) -- Daniel Rall <[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
