Answer inline: > -----Original Message----- > From: Tim Vernum [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 04, 2002 7:51 AM > To: 'Jakarta Commons Developers List' > Subject: RE: Problems with commons-logging > > > > ... > > > > Otherwise we'll still have to code against Log4j APIs ( to set the > > config file for example ) - and what's the point of using > > commons logging > > if we already require and hardcode log4j ? > > Surely the author of the app can be expected to know which logging > toolkit he/she is using?
Not always. Example: with such generic configuration mechanism it would be easier to have a pluggable logger in Tomcat. It would also be useful for the typical use of Velocity... but Velocity already implements something like that. > Commons-logging is to prevent the components from dictating a > specific logging implementation to their users. > > It is (AFAICT) intended that commons-logging would only be used > by individual components, and the users of those components > would use their preferred logging api directly. > > commons-logging exists *only* to provide an API to commons > components that wish to log without requiring a specific > logging implementation. > > Configuration is not done by a components, therefore it is > outside the scope of the common-logging package. I still do not get WHY you really need to impose such limitations. For me it makes more sense NOT to implement i18n support. Have fun, Paulo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
