For frameworks, you can't tell how the end-user will be configured. That's why we switched Tapestry over to commons-logging, so that the end-user can get the benefits of logging, regardless of whether they are using Log4J, javax.logging or something else. We also ship Log4J, since we try to maintain compatibility all the way back to JDK 1.2.
The only problem is that Tapestry originally had a special, built-in web page for creating Log4J loggers (nee categories), and changing Log4J levels (nee priorities). This used addtiional methods in Log4J Logger for setting the level, and elsewhere for creating new loggers. The commons-logging folks are pretty adamant that extrending the framework for these operations isn't appropriate. (I disagree, but it's not a fight I'm prepared to wage, or expect to win). Howard ----- Original Message ----- From: "Dani Estermann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 29, 2003 5:21 AM Subject: Logging strategy > Has jakarta got a strategy/guideline/regulation that recommends a > certain logging api to be used by jakarta projects? Are existing and > future jakarta projects allowed to choose between log4j, LogKit, > commons-logging or even JDK1.4-Logging? > > We are currently choosing a logging api and implementation to be used in > our business projects. While I favor the power of the log4j > implementation, I ask myself if it would be wise to use a -- maybe more > future-proof -- thin bridge like commons-logging on top. > > thanks, > > Daniel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
