> > (2) Add a trace() level > > > > There was a suggestion to add trace(message) and > trace(message,exception) > > methods to the commons-logging API, with the idea that trace is a level > > "below" debug. I'm personally OK with doing that *before* a > 1.0 release, > > but will likely oppose it afterwards (adding new public methods to Java > > interfaces is hard on backwards compatibility). Therefore, I think this > > is a "now or never" decision. What do you guys think? > > > > +1. I think this should be done, if it would be vetoed at a later date. > I am happy to add this myself.
Funny... somewhere between the 50K lines and the 90K lines of code in my current project, I started having doubts about the "just 5 debug levels" idea that Peter and Ceki (used to?) defend. Actually, if I had to choose just 5, I would choose: 1 TRACE 2 DEBUG 3 WARN 4 INFO 5 ERROR and skip FATAL... which (argh!) gets me a bit closer to agree with JSR047. Ok, to redeem myself a bit from such sin, I still think they (JSR47) have too many "finesse" levels and that FATAL (missing in JSR47), while maybe having a lower use count has a critical usefulness. Not to talk about the very cluttered API! Have fun, Paulo Gaspar > -----Original Message----- > From: Scott Sanders [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 8:17 PM > To: Jakarta Commons Developers List > Subject: Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release > > > On Wed, Jan 30, 2002 at 08:40:27AM -0800, Craig R. McClanahan wrote: > > Out of the "discussions" yesterday, the proposal to release > > commons-logging 1.0 received a sufficient number of +1 votes to pass. > > Howeer, three issues were raised that should be settled beforehand, in > > order to provide future users of this package with a stable > API. I'd like > > to review them individually so we can move forwards. > > > > > > (1) Attribution > > > > As was pointed out, the developers of the Avalon framework, and the > > logging abstractions and implementations they have developed, had an > > influence on the development of the Commons Logging API. In particular, > > my implementation of the JDK 1.4 wrapper was based primarily on Avalon > > code. Because of time pressures at the time, and the fact that it was > > packaged with a different package name, I spaced on the fact > that this was > > actually Avalon code, and compounded the problem by omitting the author > > names of the original authors (Berin and Peter). I apologize to both of > > them for that error, and have corrected it in the commons-logging source > > code. Please let me know if there are any remaining issues in > this area. > > > > > > (2) Add a trace() level > > > > There was a suggestion to add trace(message) and > trace(message,exception) > > methods to the commons-logging API, with the idea that trace is a level > > "below" debug. I'm personally OK with doing that *before* a > 1.0 release, > > but will likely oppose it afterwards (adding new public methods to Java > > interfaces is hard on backwards compatibility). Therefore, I think this > > is a "now or never" decision. What do you guys think? > > > > +1. I think this should be done, if it would be vetoed at a later date. > I am happy to add this myself. > > > > > (3) Change the "message" argument type from Object to String > > > > In all of the current commons-logging API, the "message" argument to all > > of the logging calls is an Object. This allows passing an Object on to > > the underlying logging implementation (currently Log4J supports > this, but > > it's also possible to write your own application-specific wrappers using > > things like the Chain of Responsibility pattern, but there is a > potential > > security concern that the logging system might call methods on > your object > > and modify its state. > > > > I believe that the security concern can be dealt with -- the calling > > program can do its own conversion to string beforehand if it is > concerned > > -- so would prefer to maintain the flexibility. Geir has proposed an > > alternative of supporting both method signatures. Comments? > > > > +0, I am fine with it staying Object, and I am fine with there being two > different methods for each. > > I am -1, however on only having a String impl. > > > > > Let's try to move towards resolution on these issues in the next day or > > so. > > > > Craig McClanahan > > > > -- > Scott Sanders - [EMAIL PROTECTED] > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
