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]>
