Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.1
    • Fix Version/s: 1.0.3
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      I am requesting that the code added to Log4JCategory in
      commons-logging-1.0.1 that sets up a default initialization in log4j be
      removed.

      Why? When I put 1.0.1 in place of 1.0, I started getting extraneous
      messages logged to the console. Subsequent research led me to the new
      initialization code in Log4JCategory. The problem is in the way the
      initialization code tries to decide if log4j has been configured. It
      assumes that the root category has been configured with an appender. I
      happen to have a log4j properties configuration that doesn't configure
      an appender, so the initialization code couldn't tell that log4j had
      been configured, it created the default root appender, and I started
      getting the extraneous messages.

      I realize there are easy workarounds for my particular problem, but I
      believe this presents a more philosophical issue. Quoting from the
      commons-logging api org.apache.commons.logging package description:

      "The basic principle is that the user is totally responsible for the
      configuration of the underlying logging system. Commons-logging should
      not change the existing configuration."

      The code in question directly violates this expressly stated principal
      and is inappropriate. Allowing this code to remain opens a Pandora's box
      of attempts to configure the underlying logger, which should be resisted
      based on the above principal.

        Activity

        Steven Caswell created issue -
        Hide
        Steve Downey added a comment -

        In practice, I think this means changing the selection mechanism for the logging
        system to use. It's not enough to see that log4j is present. If the root logger
        in log4j is not configured, then log4j can't be used. Otherwise you get errors
        printed out instructing you to correctly configure the logging system.

        OTOH, I also think it's a logical error to use log4j without configuring the
        root logger, even if only to send everything to the null appender.

        Show
        Steve Downey added a comment - In practice, I think this means changing the selection mechanism for the logging system to use. It's not enough to see that log4j is present. If the root logger in log4j is not configured, then log4j can't be used. Otherwise you get errors printed out instructing you to correctly configure the logging system. OTOH, I also think it's a logical error to use log4j without configuring the root logger, even if only to send everything to the null appender.
        Hide
        Richard A. Sitze added a comment -

        Realizing that there are OTHER complications in this,
        would looking for the presence of 'log4j.properties'
        be sufficient for everyones needs?

        Show
        Richard A. Sitze added a comment - Realizing that there are OTHER complications in this, would looking for the presence of 'log4j.properties' be sufficient for everyones needs?
        Hide
        Steve Downey added a comment -

        Not for me. I use log4j, but it's not configured using the default configuration
        mechanism. I configure explicitly, and not always from a property file name
        'log4j.properties'.

        How about this? If we're searching for a log implementation, that is,an
        implementation has not been set explicitly, and the log4j Root appender is not
        configured, move on to the next in the search list?

        I'd also like to know what Steven Caswell's desired behavior is? He's got the
        use case where Root is unconfigured, but other loggers are. What should a random
        log category do in this case. Be default, I believe Log4J will print out error
        messages, which is, in my opinion, undesireable behavior.

        Show
        Steve Downey added a comment - Not for me. I use log4j, but it's not configured using the default configuration mechanism. I configure explicitly, and not always from a property file name 'log4j.properties'. How about this? If we're searching for a log implementation, that is,an implementation has not been set explicitly, and the log4j Root appender is not configured, move on to the next in the search list? I'd also like to know what Steven Caswell's desired behavior is? He's got the use case where Root is unconfigured, but other loggers are. What should a random log category do in this case. Be default, I believe Log4J will print out error messages, which is, in my opinion, undesireable behavior.
        Hide
        Ceki Gulcu added a comment -

        Steven Caswell has said it well.

        I don't agree with Steve Downey. He says: "If the root logger
        in log4j is not configured, then log4j can't be used. Otherwise you get errors
        printed out instructing you to correctly configure the logging system."

        Log4j is designed to warn the user that it was not properly configured.

        He also states: "I also think it's a logical error to use log4j without
        configuring the root logger, even if only to send everything to the null
        appender."

        Log4j can be correctly used without ever configuring the root logger.

        Show
        Ceki Gulcu added a comment - Steven Caswell has said it well. I don't agree with Steve Downey. He says: "If the root logger in log4j is not configured, then log4j can't be used. Otherwise you get errors printed out instructing you to correctly configure the logging system." Log4j is designed to warn the user that it was not properly configured. He also states: "I also think it's a logical error to use log4j without configuring the root logger, even if only to send everything to the null appender." Log4j can be correctly used without ever configuring the root logger.
        Hide
        Steve Downey added a comment -

        I didn't mean that log4j in an application couldn't be used without a root logger configured. That's well within scope for log4j and a self contained application. But what should the semantics be for an application that uses a component that uses commons-logging that doesn't have a root appender configured? When the component goes to log, it will get an unconfigured category, and will generate errors. It might not even be the component that's of interest to the application. e.g. httpclient may use collections, which uses logging. By leaving log4j unconfigured, we force the application to become interested in logging. And removing log4j is not always feasible. It may be present to support other apps that are interested in logging. Getting log4j warnings just because you start using a commons component seems wrong.

        Show
        Steve Downey added a comment - I didn't mean that log4j in an application couldn't be used without a root logger configured. That's well within scope for log4j and a self contained application. But what should the semantics be for an application that uses a component that uses commons-logging that doesn't have a root appender configured? When the component goes to log, it will get an unconfigured category, and will generate errors. It might not even be the component that's of interest to the application. e.g. httpclient may use collections, which uses logging. By leaving log4j unconfigured, we force the application to become interested in logging. And removing log4j is not always feasible. It may be present to support other apps that are interested in logging. Getting log4j warnings just because you start using a commons component seems wrong.
        Hide
        Ceki Gulcu added a comment -

        "But what should the semantics be for an application that uses a component that
        uses commons-logging that doesn't have a root appender configured? When the
        component goes to log, it will get an unconfigured category, and will generate
        errors."

        Wrong working assumption! If the logger named "org.apache.commons.httputils" is
        configured (it has an attached appender) and, assuming httputils only uses
        loggers under "org.apache.commons.httputils", logging from httputils will not
        generate errors even if the root logger is not configured.

        Wrong assumptions => wrong conclusions.

        Show
        Ceki Gulcu added a comment - "But what should the semantics be for an application that uses a component that uses commons-logging that doesn't have a root appender configured? When the component goes to log, it will get an unconfigured category, and will generate errors." Wrong working assumption! If the logger named "org.apache.commons.httputils" is configured (it has an attached appender) and, assuming httputils only uses loggers under "org.apache.commons.httputils", logging from httputils will not generate errors even if the root logger is not configured. Wrong assumptions => wrong conclusions.
        Hide
        Steven Caswell added a comment -

        The functionality I desire is the functionality in version 1.0 of
        commons-logging. That functionality is that commons-logging makes no attempt in
        any way to apply a default configuration to log4j. And that is the fundamental
        issue I have against having commons-logging attempt to put in a default
        configuration - it shouldn't. As a developer or deployer, I should be smart
        enough to know what I want my logging system to acheive.

        Again, quoting from the commons-logging documentation:

        "The basic principle is that the user is totally responsible for the
        configuration of the underlying logging system. Commons-logging should
        not change the existing configuration."

        Existing configuration means whatever I've done to configure my logging package,
        including letting it default.

        Show
        Steven Caswell added a comment - The functionality I desire is the functionality in version 1.0 of commons-logging. That functionality is that commons-logging makes no attempt in any way to apply a default configuration to log4j. And that is the fundamental issue I have against having commons-logging attempt to put in a default configuration - it shouldn't. As a developer or deployer, I should be smart enough to know what I want my logging system to acheive. Again, quoting from the commons-logging documentation: "The basic principle is that the user is totally responsible for the configuration of the underlying logging system. Commons-logging should not change the existing configuration." Existing configuration means whatever I've done to configure my logging package, including letting it default.
        Hide
        Richard A. Sitze added a comment -

        The issue here is between those who
        a) want to use commons-logging (with default behaviour) out-of-box,
        b) want to use commons-logging in a Log4J enabled application, out-of-box.

        Both have reasonable requests & desires... the problem may be Log4J's
        difficult bootstrapping mechanism.

        It's been proposed (but nothing has yet been done) that the current content
        be packaged in a number of different ways:

        Create a commons-logging-XYZ.jar for each of LogKit, JDK14, SimpleLogger, ?
        containing:
        Log, LogFactory, appropriate LogImpl
        commons-logging.properties
        org.apache.commons.logging.Log=org.apache.commons.logging.impl.XYZ

        We could include TWO versions for Log4J if we change the current logic
        to NOT automatically defer to the Log4jFactory:

        a) Log, LogFactory, appropriate LogImpl
        commons-logging.properties
        org.apache.commons.logging.Log=org.apache.commons.logging.impl.XYZ

        b) Log, LogFactory, appropriate LogImpl, Log4jFactory
        commons-logging.properties
        org.apache.commons.logging.LogFactory=
        org.apache.commons.logging.impl.Log4jFactory

        the first would work in an environment pre-enabled for Log4J.
        The second would work in a clean environment.

        So... the solution would be to grab the jar file that fits your environment.

        Show
        Richard A. Sitze added a comment - The issue here is between those who a) want to use commons-logging (with default behaviour) out-of-box, b) want to use commons-logging in a Log4J enabled application, out-of-box. Both have reasonable requests & desires... the problem may be Log4J's difficult bootstrapping mechanism. It's been proposed (but nothing has yet been done) that the current content be packaged in a number of different ways: Create a commons-logging-XYZ.jar for each of LogKit, JDK14, SimpleLogger, ? containing: Log, LogFactory, appropriate LogImpl commons-logging.properties org.apache.commons.logging.Log=org.apache.commons.logging.impl.XYZ We could include TWO versions for Log4J if we change the current logic to NOT automatically defer to the Log4jFactory: a) Log, LogFactory, appropriate LogImpl commons-logging.properties org.apache.commons.logging.Log=org.apache.commons.logging.impl.XYZ b) Log, LogFactory, appropriate LogImpl, Log4jFactory commons-logging.properties org.apache.commons.logging.LogFactory= org.apache.commons.logging.impl.Log4jFactory the first would work in an environment pre-enabled for Log4J. The second would work in a clean environment. So... the solution would be to grab the jar file that fits your environment.
        Hide
        Mark Womack added a comment -

        Why now change the behavior of the Log4JFactory to not perform any default
        initialization, BUT extend commons-logging to allow for custom initialization
        classes that can be declared in the commons-logging properties?

        org.apache.commons.logging.LogInitializer=<whatever class you want to do
        initialization>

        This gives commons-logging users of all log packages the opportunity to
        initialize correctly according to the log package being used and/or product it
        is being used within.

        Show
        Mark Womack added a comment - Why now change the behavior of the Log4JFactory to not perform any default initialization, BUT extend commons-logging to allow for custom initialization classes that can be declared in the commons-logging properties? org.apache.commons.logging.LogInitializer=<whatever class you want to do initialization> This gives commons-logging users of all log packages the opportunity to initialize correctly according to the log package being used and/or product it is being used within.
        Hide
        Steven Caswell added a comment -

        I'd be happy with the latest proposal, esp. if log4j did nothing beyond calling
        the log initializer class. At least then I'd have control over having it do or
        not do initialization.

        Show
        Steven Caswell added a comment - I'd be happy with the latest proposal, esp. if log4j did nothing beyond calling the log initializer class. At least then I'd have control over having it do or not do initialization.
        Hide
        Craig McClanahan added a comment -

        Picking up this thread as I'm reviewing commons-logging in prep for a 1.0.3 release.

        I agree with Steven Caswell's original request – commons-logging should make
        absolutely no attempt to configure the underlying loggging implementation.
        Instead, either the app should preconfigure the implementation the way it wants,
        or the implementation should provide a mechanism for self-configuration.

        (Ceki, my understanding is that this is not true for Log4J, right? If there's a
        "log4j.properties" file then it will be used to configure things if config was
        not done directly by the application?)

        Further discussion about this will happen on COMMONS-DEV shortly.

        Show
        Craig McClanahan added a comment - Picking up this thread as I'm reviewing commons-logging in prep for a 1.0.3 release. I agree with Steven Caswell's original request – commons-logging should make absolutely no attempt to configure the underlying loggging implementation. Instead, either the app should preconfigure the implementation the way it wants, or the implementation should provide a mechanism for self-configuration. (Ceki, my understanding is that this is not true for Log4J, right? If there's a "log4j.properties" file then it will be used to configure things if config was not done directly by the application?) Further discussion about this will happen on COMMONS-DEV shortly.
        Hide
        Ceki Gulcu added a comment -

        Log4j does not provide a "default" configuration. However, if at static
        initailization time, log4j can find a resource called log4j.xml or
        log4j.properties, it will use that configration file. The name of the files to
        search for can be specified by the user. I hope this answers the question,

        Show
        Ceki Gulcu added a comment - Log4j does not provide a "default" configuration. However, if at static initailization time, log4j can find a resource called log4j.xml or log4j.properties, it will use that configration file. The name of the files to search for can be specified by the user. I hope this answers the question,
        Hide
        Craig McClanahan added a comment -

        As discussed in the thread on this bug report, the attempt to configure Log4J
        has been removed from Log4JLogger and Log4JCategoryLog. Fixed in nightly build
        20030402.

        Show
        Craig McClanahan added a comment - As discussed in the thread on this bug report, the attempt to configure Log4J has been removed from Log4JLogger and Log4JCategoryLog. Fixed in nightly build 20030402.
        Hide
        Ceki Gulcu added a comment -
            • *** Bug 19026 has been marked as a duplicate of this bug. *** has been marked as a duplicate of this bug. ***
        Show
        Ceki Gulcu added a comment - *** Bug 19026 has been marked as a duplicate of this bug. *** has been marked as a duplicate of this bug. ***
        Henri Yandell made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 13201 12340345
        Henri Yandell made changes -
        Affects Version/s 1.0.1 Final [ 12311660 ]
        Project Commons [ 12310458 ] Commons Logging [ 12310484 ]
        Key COM-194 LOGGING-41
        Assignee Jakarta Commons Developers Mailing List [ commons-dev@jakarta.apache.org ]
        Component/s Logging [ 12311124 ]
        Henri Yandell made changes -
        Affects Version/s 1.0.1 Final [ 12311824 ]
        Dennis Lundberg made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Dennis Lundberg made changes -
        Status Closed [ 6 ] Reopened [ 4 ]
        Dennis Lundberg made changes -
        Resolution Fixed [ 1 ]
        Status Reopened [ 4 ] Resolved [ 5 ]
        Henri Yandell made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Dennis Lundberg made changes -
        Fix Version/s 1.0.3 [ 12311839 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Closed Closed Reopened Reopened
        17h 43m 1 Dennis Lundberg 18/Nov/06 12:46
        Reopened Reopened Resolved Resolved
        1m 58s 1 Dennis Lundberg 18/Nov/06 12:48
        Resolved Resolved Closed Closed
        1916d 17h 56m 2 Henri Yandell 02/Jan/08 07:48

          People

          • Assignee:
            Unassigned
            Reporter:
            Steven Caswell
          • Votes:
            4 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development