commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [logging] work needed for 1.0.4 [WAS Re: [logging] Are we ready for 1.0.4?]
Date Mon, 01 Mar 2004 02:04:55 GMT
Quoting robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>:

> On 28 Feb 2004, at 19:37, Dennis Lundberg wrote:
> 
> > Here is a status for bugs regarding logging:
> >
> > #10818 [logging] Add method enter() and exit() methods to public Log 
> > API
> 
> this means breaking the Log interface. there is some utility in this 
> proposal but i think that log is so widely used that backwards 
> compatibility is crucial. i'd probably support rejecting this one.
> 

I agree with Robert.  In addition, not all of the logging implementations
support this sort of thing, so this change would violate the principle that c-l
is a simple wrapper around the existing functionality.  Therefore, I'm leaning
towards -1 on this, even in a 2.0 version of c-l.

How, for example, would Log4JLogger implement such calls since Log4J doesn't
support these notions?

> > #21114 [logging] Create Log factory method getLog()
> 
> ditto

-1 as well.

Log is an interface because the whole point of the package is to be a *wrapper*
around existing implementations.  If you don't want to use LogFactory, then
just call "new SimpleLog()" or whatever yourself, or provide your own factory
-- although that, of course, would defeat the purpose of your proposed
enhancement. 

> 
> > - These involve changing the public API, so it's not something we can 
> > do in a point release. Should these be marked as LATER in bugzilla?
> 
> these involve breaking backward compatibility and would require a full 
> version change. we could probably mark them LATER and add for 
> consideration in commons-logging 2. comments anyone?
> 

For the reasons stated above, I don't like them even in a c-l version 2.

> > #25156 [logging] Enhance error message for 
> > "org.apache.commons.logging.impl.Log4JLogger does not implement Log"
> > - This seems to me to be similar to #26598
> 
> i'd like to put a fix in for this but i think a little bit of 
> discussion is required. i'll probably start a separate thread.
> 

I'll follow up on the separate thread.

> > #25940 [logging] SimpleLog.java adds extra - characters
> > - This one's mine. There is a patch available for this one that is 
> > pretty starightforward. The format of the log message needed some 
> > work.
> 
> fixed
> 
> > #26598 [logging] org.apache.commons.logging.impl.LogFactoryImpl does 
> > not provide enough information on an InvocationTargetException in the 
> > newInstance() method.
> > - This is something that has to be decided on. It involves catching an 
> > extra Exception to provide a better error-message. Code that shows how 
> > to do it is available in the bugreport.
> 
> see 25156 above
> 
> > #27135 [logging] SimpleLog log method should defer writing for better 
> > reuse!
> > - This is something for the architects to decide. The key question 
> > here is whether subclassing SimpleLog should be allowed.
> 
> i'm inclined to discourage subclassing of SimpleLog but i don't feel 
> very strongly on this issue (i can't see there being much harm). anyone 
> else have any comments?
> 

I can buy into this one, and will go ahead and do the commit.

We recently removed the "final" declaration on the implementation classes, so we
should go ahead and factor internal things to make subclassing easier when it
makes sense.

> > Other things that needs to be done:
> >
> > * I guess someone has to update all the files to the new licence.
> 
> done
> 
> > * I proofread the mavenized user guide earlier from a syntactic 
> > perspective. Someone should read it form the semantic perspective.
> 
> i'll get started on proofreading the user guide now.
> 
> - robert

Craig


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


Mime
View raw message