Почему Grails (в Tomcat) регистрируется как с catalina.out, так и с моим пользовательским файловым приложением?

У меня есть следующее для моей конфигурации log4j DSL в Grails 1.2:

log4j = {
    appenders {
        console name: 'stdout', layout: pattern(conversionPattern: conversionPattern)

        environments {
            production {
                // ... some code to determine file path ...

                rollingFile name: 'file', file: "${logDirectory}/${appName}.log", layout: pattern(conversionPattern: conversionPattern)
                rollingFile name: 'StackTrace', file: "${logDirectory}/${appName}-stacktrace.log"
        }
    }

    environments {
        development { root { warn 'stdout' } }
        test { root { warn 'stdout' } }
        production { root { error 'file' } }
    }

    // ... package-specific logging configurations ...
}

Когда я развертываюсь в качестве войны с Tomcat, мои журналы записываются в файл catalina.out и мой "файл", определенный для производства.

Я пробовал:

  • добавление additivity = false в определение root {} для production {}, которое не работает (и я бы этого не ожидал, поскольку он, по-видимому, устанавливал аддитивность для самого корневого регистратора?).
  • определение консольного приложения 'stdout' внутри блока development {} и test {} внутри закрытия appenders {}, но это тоже не работает.

Возможно, это проблема с моей конфигурацией Tomcat, а не с DSL log4j? Ближайший я пришел найти кого-то с аналогичной проблемой этот поток рассылки, для которого не было (простого) решения.

Как я могу запретить запись журналов в каталину. в процессе производства?

Ответ 1

Мне удалось обойти проблему, выполнив следующее в Config.groovy:

import org.apache.log4j.Logger

log4j = {
    // ... configuration from question ...
}

environments {
    production {
        def logger = Logger.getRootLogger()
        logger.removeAppender('stdout')
    }
}

Тем не менее, это похоже на грязный взломать, и я надеюсь, что там будет лучше, Grails log4j DSL-специфический способ сделать это.

Кроме того, что-либо, что приложение может выполнить для записи в stdout, вероятно, не будет написано, что может быть плохо, если есть журналы/исключения/stacktraces, которые каким-то образом записываются непосредственно в stdout.