Now this one comes through :) Disregard this as I now agree with Geir's debate on the subject.
> -----Original Message----- > From: Scott Sanders [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 11:17 AM > 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]>
