You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Steve Loughran (JIRA)" <ji...@apache.org> on 2008/05/08 18:19:16 UTC

[jira] Created: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

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

                 Key: HADOOP-3368
                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
             Project: Hadoop Core
          Issue Type: Improvement
    Affects Versions: 0.16.3
            Reporter: Steve Loughran


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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617456#action_12617456 ] 

Hadoop QA commented on HADOOP-3368:
-----------------------------------

-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.

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.19.0
>            Reporter: Steve Loughran
>         Attachments: hadoop-3368.patch
>
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595355#action_12595355 ] 

Doug Cutting commented on HADOOP-3368:
--------------------------------------

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


> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.16.3
>            Reporter: Steve Loughran
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Steve Loughran (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Loughran updated HADOOP-3368:
-----------------------------------

    Affects Version/s:     (was: 0.16.3)
                       0.19.0
               Status: Patch Available  (was: Open)

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.

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.19.0
>            Reporter: Steve Loughran
>         Attachments: hadoop-3368.patch
>
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Steve Loughran (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Loughran updated HADOOP-3368:
-----------------------------------

    Attachment: hadoop-3368.patch

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.16.3
>            Reporter: Steve Loughran
>         Attachments: hadoop-3368.patch
>
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Owen O'Malley (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Owen O'Malley reassigned HADOOP-3368:
-------------------------------------

    Assignee: Steve Loughran

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.19.0
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>         Attachments: hadoop-3368.patch
>
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624665#action_12624665 ] 

Hudson commented on HADOOP-3368:
--------------------------------

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

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.19.0
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>             Fix For: 0.19.0
>
>         Attachments: hadoop-3368.patch
>
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595337#action_12595337 ] 

Doug Cutting commented on HADOOP-3368:
--------------------------------------

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...

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.16.3
>            Reporter: Steve Loughran
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Robert Chansler (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Chansler updated HADOOP-3368:
------------------------------------

    Component/s: build

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>          Components: build
>    Affects Versions: 0.19.0
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>             Fix For: 0.19.0
>
>         Attachments: hadoop-3368.patch
>
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Owen O'Malley (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Owen O'Malley updated HADOOP-3368:
----------------------------------

    Fix Version/s: 0.19.0

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.19.0
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>             Fix For: 0.19.0
>
>         Attachments: hadoop-3368.patch
>
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HADOOP-3368) Can commons-logging.properties be pulled from hadoop-core?

Posted by "Owen O'Malley (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HADOOP-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Owen O'Malley updated HADOOP-3368:
----------------------------------

      Resolution: Fixed
    Hadoop Flags: [Reviewed]
          Status: Resolved  (was: Patch Available)

I just committed this. Thanks, Steve!

> Can commons-logging.properties be pulled from hadoop-core?
> ----------------------------------------------------------
>
>                 Key: HADOOP-3368
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3368
>             Project: Hadoop Core
>          Issue Type: Improvement
>    Affects Versions: 0.19.0
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>         Attachments: hadoop-3368.patch
>
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.