Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.9.7
    • Fix Version/s: 0.10.0
    • Component/s: Configurator
    • Labels:
      None
    • Environment:
      Linux (SuSE)

      Description

      log4cxx's current default initializion is broken on Linux (and possibly a large number of other systems), because log4cxx sticks a little too close to log4j's ideas:

      The current mechanism is using environment variables containing
      a dot for its configuration. As stated in the short introduction:
      "The preferred way to specify the default initialization file is through the log4j.configuration environment variable."

      The problem is, that it's impossible to create environment variables containing a dot on Linux systems, meaning you're unable to use the preferred way of default initialization on Linux...

      I've created a small, backward-compatible patch, that goes on
      to check a few additional environment variables (LOG4J_CONFIGURATION
      and LOG4CXX_CONFIGURATION) if log4j.configuration is unset allowing
      UNIX-types to use these instead of the ones with the dot. The patch
      also updates the documentation in the short introduction.

        Activity

        Hide
        Curt Arnold added a comment -

        Thanks for the patch. I've taken a slightly different take on the resolution. Using "log4j." environment variables was misguided in my judgement since log4j configuration is through Java VM properties not environment variables. The existing log4j. environment variables need to be supported for compatibility, however I've given the "LOG4CXX_" environment variables and the "log4cxx." files precedence over their log4j.* equivalents. So if a directory has log4j.properties and log4cxx.properties, then one will be used to configure Java apps and the other for C++ apps. That seems more desirable than using log4j.properties to control both and ignore the log4cxx.properties file.

        I'd be surprised if this (or the existing code) builds on Win32 since "stat" is typically "_stat" on that platform, but I'm pretty sure that build has been broken for a couple of months and I'll fix it up in one go.

        I've modified build.xml so that the default configuration unit test
        is run under additional scenarios, with LOG4CXX_CONFIGURATION environment variable set and with log4cxx.properties and log4j.properties files present.

        CVS commit message: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-dev@logging.apache.org&msgNo=319

        Show
        Curt Arnold added a comment - Thanks for the patch. I've taken a slightly different take on the resolution. Using "log4j. " environment variables was misguided in my judgement since log4j configuration is through Java VM properties not environment variables. The existing log4j. environment variables need to be supported for compatibility, however I've given the "LOG4CXX_ " environment variables and the "log4cxx. " files precedence over their log4j.* equivalents. So if a directory has log4j.properties and log4cxx.properties, then one will be used to configure Java apps and the other for C++ apps. That seems more desirable than using log4j.properties to control both and ignore the log4cxx.properties file. I'd be surprised if this (or the existing code) builds on Win32 since "stat" is typically "_stat" on that platform, but I'm pretty sure that build has been broken for a couple of months and I'll fix it up in one go. I've modified build.xml so that the default configuration unit test is run under additional scenarios, with LOG4CXX_CONFIGURATION environment variable set and with log4cxx.properties and log4j.properties files present. CVS commit message: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-dev@logging.apache.org&msgNo=319
        Hide
        Martin Landers added a comment -

        Patch fixing the initialization issue.

        Show
        Martin Landers added a comment - Patch fixing the initialization issue.

          People

          • Assignee:
            Curt Arnold
            Reporter:
            Martin Landers
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development