I personally believe that a fatal 'log' should just be an Exception, but I could be wrong :)
Scott > -----Original Message----- > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 2:33 PM > To: Jakarta Commons Developers List > Subject: RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release > > > > > (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:commons-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
