commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Date Wed, 30 Jan 2002 22:32:54 GMT
> > (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.

Funny... somewhere between the 50K lines and the 90K lines of code in my
current project, I started having doubts about the "just 5 debug levels"
idea that Peter and Ceki (used to?) defend.

Actually, if I had to choose just 5, I would choose:
 1 TRACE
 2 DEBUG
 3 WARN
 4 INFO
 5 ERROR

and skip FATAL... which (argh!) gets me a bit closer to agree with JSR047.

Ok, to redeem myself a bit from such sin, I still think they (JSR47) have
too many "finesse" levels and that FATAL (missing in JSR47), while maybe
having a lower use count has a critical usefulness. Not to talk about the
very cluttered API!


Have fun,
Paulo Gaspar


> -----Original Message-----
> From: Scott Sanders [mailto:sanders@apache.org]
> Sent: Wednesday, January 30, 2002 8:17 PM
> 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 - sanders@apache.org
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message