----- Original Message ----- From: "Jeff Schnitzer" <[EMAIL PROTECTED]> To: "Jakarta General List" <[EMAIL PROTECTED]> Sent: Thursday, March 28, 2002 2:12 PM Subject: RE: Comments on the commons-logging API
> > From: Morgan Delagrange [mailto:[EMAIL PROTECTED]] > > > > Yes, the defining advantage to the commons-logging API that I see is that > > it > > allows users to adopt a single logging implementation, which confers real > > What needs to be appended to that statement is "...if everyone codes to > the commons-logging API". Every component that uses the Commons Logging proxy will play well with every other component using the proxy, _plus_ all code using a single logger implementation of your choice. Saying that everyone must code to the commons-logging API is an oversimplification. More accurately, coding to commons-logging facilitates integration with a single arbitrary logging implementation. Any environment that uses a combination of the logging facade and a single logging implementation will work well. Any environment that uses more than one logging implementation will not work as well. > The exact same statement can be reconstructed > using "Log4J API" and it is equally true. If you can guarantee that: 1) All Jakarta developers will use Log4J in their code, eschewing even LogKit, another logging implementation under the Jakarta umbrella. and 2) All Jakarta _users_ will use Log4J in their code. then there is no need for a proxy logger. > If everyone uses commons-logging, then only one logger must be > configured. If everyone uses Log4J, then only one logger must be > configured. Where is this world where "everyone" uses Log4J? > If third-party software is using different loggers, then > you have to configure multiple loggers no matter what API your code > uses. Unless that third-party is Jakarta, and that software is utilizing a proxy logger like commons-logging. That's the whole point, we can't (and shouldn't) dictate what implementations others may choose to use. We can, however, facilitate integration with their implementation. Or we can leave them to the wolves. > It seems to me that the commons-logging API just adds Yet Another > Logging API... especially when someone gets the bright idea to make a > "native" implementation of the API for performance reasons. > > At least with Turbine, Struts, (Maverick :-), etc, there are some > fundamentally different approaches to the problem of how to publish a > web application. Logging doesn't seem that complicated. The massive > duplication of this basic feature in the Jakarta codebase is silly, and > trying to build an abstraction layer on top of it seems even sillier. I'm not sure what "massive duplication" you're referring to, but you seem to believe that an abstraction layer is unimportant because you think everyone should use Log4J. I think the LogKit folks would disagree. I do too; for simple logging in a JDK 1.4 environment, using the built-in logger should be perfectly acceptable. Because I made that choice, does that mean I should not get any output from Jakarta components in my log? - Morgan > Jeff Schnitzer > [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
