commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <>
Subject Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Date Wed, 30 Jan 2002 17:09:15 GMT

----- Original Message -----
From: "Craig R. McClanahan" <>
To: <>
Sent: Wednesday, January 30, 2002 10:40 AM
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.


> (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?

0.  Neither for nor agin it.

> (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?

I'm +1 on maintaining the current approach.  Objects are more flexible.
Even if you are not using Log4J, you can and may want to introduce your own
implementation of the Logging interface to interact with particular objects
before passing them onto another logger.  So basing the interface on Objects
is not necessarily specific to Log4J.

Also, the Sun JDK 1.3.1 implementation of String.toString() is amazingly

     * This object (which is already a string!) is itself returned.
     * @return  the string itself.
    public String toString() {
      return this;



> Let's try to move towards resolution on these issues in the next day or
> so.
> Craig McClanahan
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Get your free address at

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message