> -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 8:40 AM > To: [EMAIL PROTECTED] > Subject: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release > > > 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.
None here. > > > (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 would very much like a trace() level. > > > (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. +1. I would like to see all methods done as String. This is as simple as it can possibly get, and I am all about the simplicity. > > 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. +0 on both. I would actually prefer just the string, but would not prevent the object. > Comments? > > > Let's try to move towards resolution on these issues in the > next day or so. > > Craig McClanahan > Scott -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
