Can commons-logging.properties be pulled from hadoop-core?

• Key: HADOOP-3368
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Steve Loughran
• Reporter: Steve Loughran
• Component/s: build
• Affects Version/s: 0.19.0
• Fix Version/s: 0.19.0

Description

In the root of hadoop-core.jar is a log4j.properties and a commons-logging.properties

while this provides good standalone functionality to hadoop, it complicates anyone else trying to control the logging, and use the libraries in-process.

In particular, there is a commons-logging.properties file that selects Log4J as the back end. This is not needed as
-log4j is automatically picked up if it is on the classpath
-if it is not on the classpath, asking for it is generally considered bad form
If you look at the commons-logging configuration details:
http://commons.apache.org/logging/guide.html#Configuration
you will see that that such a properties file takes priority over any setting through system properties, which makes it very hard to override the settings without adding multiple commons-logging.properties files and playing with their priority settings

If you pull the commons-logging.properties file from hadoop-core log4j will still be picked up by default, but it becomes easier for people to turn on different logging infrastructures if they want to. It should have no visible impact on the end user experience (unlike pulling log4j.properties)

Comments

[Doug Cutting]

This sounds reasonable to me. Does anyone else remember why this was bundled into the jar? I'd poke around with 'svn blame' but svn.apache.org is too slow right now...

[Doug Cutting]

Found it. This dates from HADOOP-276. Both the commons-logging.properties and log4j.properties were added to the jar then. It looks like that was overkill, that just adding log4j.properties would have been sufficient.

http://svn.apache.org/viewvc/lucene/hadoop/trunk/build.xml?r1=411933&r2=411932&pathrev=411933

[Steve Loughran]

This is the operation to delete commons-logging.properties, and so let commons-logging work it out for itself. Whenever log4j is on the classpath, it gets picked up, but it will now fall back to simple text output, and support property-driven overrides. No tests.

[Hadoop QA]

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12387030/hadoop-3368.patch
against trunk revision 679930.

+1 @author. The patch does not contain any @author tags.

-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no tests are needed for this patch.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

+1 findbugs. The patch does not introduce any new Findbugs warnings.

+1 release audit. The applied patch does not increase the total number of release audit warnings.

+1 core tests. The patch passed core unit tests.

+1 contrib tests. The patch passed contrib unit tests.

Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/2959/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/2959/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/2959/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/2959/console

This message is automatically generated.

[Owen O'Malley]

I just committed this. Thanks, Steve!

[Hudson]

Integrated in Hadoop-trunk #581 (See http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/581/)