Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-337

Invalid multiple configuration file warning

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.17
    • Fix Version/s: 1.0.4
    • Component/s: logback-classic
    • Labels:
      None
    • Environment:

      Resin webapp

      Description

      I receive strange warnings in the status info. It says that logback.xml, which in this case comes from a file and not from the classpath, occurs multiple times. The file is specifies and logged using absolute path, so even relative paths cannot cause the warning.

      Logback configuration file is specified by the system property "logback.configurationFile". It is done by the Resin application server, somehow it is able to supply different properties for different web applications. I don't think this is important, however. Maybe I am doing something wrong, but at least the message doesn't help.

      20:36:34,236 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource file:/C:/Progra~1/mireka/conf/logback.xml at file:/C:/Progra~1/mireka/conf/logback.xml
      20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource file:/C:/Progra~1/mireka/conf/logback.xml occurs multiple times on the classpath.
      20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource file:/C:/Progra~1/mireka/conf/logback.xml occurs at file:/C:/Progra~1/mireka/conf/logback.xml
      20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource file:/C:/Progra~1/mireka/conf/logback.xml occurs at file:/C:/Progra~1/mireka/conf/logback.xml
      20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource file:/C:/Progra~1/mireka/conf/logback.xml occurs at file:/C:/Progra~1/mireka/conf/logback.xml

        Activity

        Hide
        derekmahar Derek Mahar added a comment - - edited

        I encounter a similar problem when using Logback 0.9.21, SLF4J 1.6.0, and running in a WebLogic 10.3.2 server container. We have separate Web and EJB applications, both of which use Logback and SLF4J.

        16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
        16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml
        16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath.
        16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml
        16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml
        16:50:25,923 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
        16:50:25,924 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@1a15291 - Will scan for changes in file [/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] every 60 seconds.

        Show
        derekmahar Derek Mahar added a comment - - edited I encounter a similar problem when using Logback 0.9.21, SLF4J 1.6.0, and running in a WebLogic 10.3.2 server container. We have separate Web and EJB applications, both of which use Logback and SLF4J. 16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext [default] - Could NOT find resource [logback-test.xml] 16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext [default] - Found resource [logback.xml] at file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml 16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext [default] - Resource [logback.xml] occurs multiple times on the classpath. 16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext [default] - Resource [logback.xml] occurs at file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml 16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext [default] - Resource [logback.xml] occurs at file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml 16:50:25,923 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 16:50:25,924 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@1a15291 - Will scan for changes in file [/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] every 60 seconds.
        Hide
        derekmahar Derek Mahar added a comment - - edited

        Robert Elliot explains in http://marc.info/?l=logback-user&m=128094084217480&w=2 how this bug occurs when running an application in a WebLogic server context. The reason that this happens may be the same reason for http://bugzilla.slf4j.org/show_bug.cgi?id=138 in SLF4J. See additional discussion of this issue in http://stackoverflow.com/questions/3401051/suppress-all-logback-output-to-console.

        Show
        derekmahar Derek Mahar added a comment - - edited Robert Elliot explains in http://marc.info/?l=logback-user&m=128094084217480&w=2 how this bug occurs when running an application in a WebLogic server context. The reason that this happens may be the same reason for http://bugzilla.slf4j.org/show_bug.cgi?id=138 in SLF4J. See additional discussion of this issue in http://stackoverflow.com/questions/3401051/suppress-all-logback-output-to-console .
        Hide
        derekmahar Derek Mahar added a comment - - edited

        Changing the return value of method getResourceOccurenceCount(String, ClassLoader) from "List<URL>" to "Set<URL>" in class ch.qos.logback.core.util.Loader should resolve this issue:

        public static List<URL> getResourceOccurenceCount(String resource,
        ClassLoader classLoader) throws IOException {
        List<URL> urlList = new ArrayList<URL>();
        Enumeration<URL> urlEnum = classLoader.getResources(resource);
        while (urlEnum.hasMoreElements())

        { URL url = urlEnum.nextElement(); urlList.add(url); }

        return urlList;
        }

        Method multiplicityWarning(String, ClassLoader) in class ch.qos.logback.classic.util.ContextInitializer uses this method to decide whether or not to print the multiple classpath entry warning:

        private void multiplicityWarning(String resourceName, ClassLoader classLoader) {
        List<URL> urlList = null;
        StatusManager sm = loggerContext.getStatusManager();
        try

        { urlList = Loader.getResourceOccurenceCount(resourceName, classLoader); }

        catch (IOException e)

        { sm.add(new ErrorStatus("Failed to get url list for resource [" + resourceName + "]", loggerContext, e)); }

        if (urlList != null && urlList.size() > 1) {
        sm.add(new WarnStatus("Resource [" + resourceName + "] occurs multiple times on the classpath.",
        loggerContext));
        for (URL url : urlList)

        { sm.add(new WarnStatus("Resource [" + resourceName + "] occurs at [" + url.toString() + "]", loggerContext)); }

        }
        }

        Note that this is the state of the code as of release 0.9.24 (http://github.com/derekmahar/logback/tree/v_0.9.24 or commit http://github.com/ceki/logback/commit/10b6686ab92a53f860b14953ce8493d5c3534a46 ).

        Show
        derekmahar Derek Mahar added a comment - - edited Changing the return value of method getResourceOccurenceCount(String, ClassLoader) from "List<URL>" to "Set<URL>" in class ch.qos.logback.core.util.Loader should resolve this issue: public static List<URL> getResourceOccurenceCount(String resource, ClassLoader classLoader) throws IOException { List<URL> urlList = new ArrayList<URL>(); Enumeration<URL> urlEnum = classLoader.getResources(resource); while (urlEnum.hasMoreElements()) { URL url = urlEnum.nextElement(); urlList.add(url); } return urlList; } Method multiplicityWarning(String, ClassLoader) in class ch.qos.logback.classic.util.ContextInitializer uses this method to decide whether or not to print the multiple classpath entry warning: private void multiplicityWarning(String resourceName, ClassLoader classLoader) { List<URL> urlList = null; StatusManager sm = loggerContext.getStatusManager(); try { urlList = Loader.getResourceOccurenceCount(resourceName, classLoader); } catch (IOException e) { sm.add(new ErrorStatus("Failed to get url list for resource [" + resourceName + "]", loggerContext, e)); } if (urlList != null && urlList.size() > 1) { sm.add(new WarnStatus("Resource [" + resourceName + "] occurs multiple times on the classpath.", loggerContext)); for (URL url : urlList) { sm.add(new WarnStatus("Resource [" + resourceName + "] occurs at [" + url.toString() + "]", loggerContext)); } } } Note that this is the state of the code as of release 0.9.24 ( http://github.com/derekmahar/logback/tree/v_0.9.24 or commit http://github.com/ceki/logback/commit/10b6686ab92a53f860b14953ce8493d5c3534a46 ).
        Hide
        derekmahar Derek Mahar added a comment -

        Please note that this is a production issue for me since our production environment disallows applications to write messages to standard output. Since this duplicate classpath entry message causes Logback to write warning and informational messages to standard output, this may prevent us from releasing our application into production.

        Show
        derekmahar Derek Mahar added a comment - Please note that this is a production issue for me since our production environment disallows applications to write messages to standard output. Since this duplicate classpath entry message causes Logback to write warning and informational messages to standard output, this may prevent us from releasing our application into production.
        Hide
        derekmahar Derek Mahar added a comment - - edited

        I have implemented a fix for this problem at http://github.com/derekmahar/logback/commit/1990e7c9c0e35ba408f73a2c654e8d292a0849af that essentially does what Robert Elliot recommends in http://marc.info/?l=logback-user&m=128094084217480&w=2 and uses a set instead of a list to hold the resources that the classloader returns, effectively eliminating any duplicate classpath resources. I have successfully tested the fix with Logback 0.9.24, SLF4J 1.6.1, and WebLogic 10.3.2. With this fix in place, Logback no longer displays the duplicate classpath entry status messages (or any of the other informational messages) to standard output.

        Show
        derekmahar Derek Mahar added a comment - - edited I have implemented a fix for this problem at http://github.com/derekmahar/logback/commit/1990e7c9c0e35ba408f73a2c654e8d292a0849af that essentially does what Robert Elliot recommends in http://marc.info/?l=logback-user&m=128094084217480&w=2 and uses a set instead of a list to hold the resources that the classloader returns, effectively eliminating any duplicate classpath resources. I have successfully tested the fix with Logback 0.9.24, SLF4J 1.6.1, and WebLogic 10.3.2. With this fix in place, Logback no longer displays the duplicate classpath entry status messages (or any of the other informational messages) to standard output.
        Hide
        peter_mc_j Peter Johansson added a comment -

        This bug is the only issue that disallows our company to use logback, please make Derek Mahars patch in to main master

        Show
        peter_mc_j Peter Johansson added a comment - This bug is the only issue that disallows our company to use logback, please make Derek Mahars patch in to main master
        Hide
        noreply.ceki@qos.ch Ceki Gulcu added a comment - - edited

        Many thanks to Derek Mahar for providing a patch. Fixed in http://github.com/ceki/logback/commit/617c073bff211

        Show
        noreply.ceki@qos.ch Ceki Gulcu added a comment - - edited Many thanks to Derek Mahar for providing a patch. Fixed in http://github.com/ceki/logback/commit/617c073bff211

          People

          • Assignee:
            noreply.ceki@qos.ch Ceki Gulcu
            Reporter:
            hontvari3@solware.com Hontvári József
          • Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: