commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [VOTE] Release RC10 As Commons Logging 1.1
Date Mon, 01 May 2006 22:20:10 GMT
robert burrell donkin wrote:
> after some investigation, the issue which turned up with RC8 was
> determined not to be a bug. notes have been added to the troubleshooting
> documentation. 
> RC10 is available from:
> please download,
> check and then vote.


Sorry to be jumping into this at the last minute. I've done a code 
review of /src/java and /xdocs and compared them to the 1.0.4 release. 
As you might have seen I committed some spelling corrections to the 
xdocs. The added documents are excellent by the way!

There were a couple of questions that popped up along the way, which I 
will deal with below, one file at a time. Nothing big, mostly 
documentation stuff, so nothing to hold up a release.

The attached patch file fixes a couple of them, while others need input 
from you. I didn't want to commit the patch before I had checked it with 
the rest of you.

I hope to be doing some practical tests in applet environments tomorrow.


Lines 147-150:
"Previous releases of commons-logging-api.jar contained the Jdk14Logger 
this is now deprecated. It will be removed from the API jar in some future
release. If your application needs this jar, then instead of
upgrading to commons-logging-api-1.1.jar, upgrade to 

I don't see why we advice this. The jar still contains Jdk14Logger. 
Should we encourage people to switch jars now or when JCL 2 comes out?

Lines 173-174:
"File commons-logging-api-nn.jar provides no adapters to external logging
libraries, just the internally implemented SimpleLog and NoOpLog classes."

This is not entirely true. The Jdk14Logger is there as well.

There is nothing in the release notes about the fact that AvalonLogger 
no longer implements Serializable. Do we need that?


Line 251: Javadoc for trace(Object message, Throwable t) was changed 
like this:
   @see org.apache.commons.logging.Log#trace(java.lang.Object, 
java.lang.Throwable)  --->  @see 
org.apache.commons.logging.Log#debug(Object, Throwable)
   Should be changed back.
   (done in patch)


Line 42: A since-tag of "1.1" was added, but the class existed in SCM 
when the previous version was released, but was not included in the jar. 
Should the since tag be there?


Line 121: The sentence seems to not have been finished...
Lines 173-175: Could use the constants that were defined in lines 74-78.
Line 761,1322: Missing indentation
   (done in patch)
Line 1252: Should be removed, copy-and-paste error
   (done in patch)


Line 398: The javadoc below
   @see org.apache.commons.logging.Log#trace(Object, Throwable)
should be
   @see org.apache.commons.logging.Log#trace(Object)
   (done in patch)

Line 142: Should be changed
   </code></pre>  --->  </pre></code>
   (done in patch)
Lines 335-340, 1130, 1219-1271: Indentation is wrong (is using 
   (done in patch)
Line 574: Should this be converted into a @todo?
Line 1172: LogFactory.class.getClassLoader.load(name)  ---> 
   (done in patch)
Line 1217: The last part of the JavaDocs are cut in the middle of a 
sentence. What should it say?
Lines 1462, 1466: The file doesn't have to be called FACTORY_PROPERTIES, 
the name is given by the parameter "fileName". The method is private and 
is only called once with fileName=FACTORY_PROPERTIES. Should this be 
"org.apache.commons.logging.diagnostics.dest". Which one is best?
Line 1655: Missing a space at the end of the string (after the colon)
   (done in patch)

Line 150: Remove " in each file".
   (done in patch)

Line 649:
   "JCL uses the context classloader to use the <code>Log</code> 
What should it be?
   "JCL uses the context classloader to get|load the <code>Log</code> 

Line 91:
   "Each diagnostic message is prefixed with details of the class being 
logger in a standard format."
What should it be?
   "Each diagnostic message is prefixed with details of the class being 
logged|loaded|diagnosed in a standard format."

Dennis Lundberg

View raw message