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? (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? Let's try to move towards resolution on these issues in the next day or so. Craig McClanahan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
