как подавить унаследованный logback проектов.xml-файл (2 logback.XML в одном проекте)?

у меня есть проект com.samedhi / base что есть Logback так.в XML файл и проект com.samedhi / derive, что также имеет Logback так.в XML. Проект'вывести' зависит от 'базовый'. Когда Я"lein trampoline repl "on'вывести', Я получаю следующее предупреждение.

....
15:34:30,066 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
15:34:30,066 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
15:34:30,066 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/stephen/Work/com.samedhi/derive/client/config/logback.xml]
15:34:30,067 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath.
15:34:30,067 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [jar:file:/home/stephen/.m2/repository/com/samedhi/base.app/0.0.1-SNAPSHOT/base.app-0.0.1-SNAPSHOT.jar!/logback.xml]
15:34:30,067 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/home/stephen/Work/com.samedhi/derive/client/config/logback.xml]
15:34:30,129 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
....

Итак, проблема заключается в том, что у меня есть два logback.xml в моем пути к классам. Что мне делать с " surpress" в Logback так.XML из проекта 'базовый ' когда я lein repl от 'вывести'?

4 ответов


насколько мне известно, вы никогда не должны упаковывать файл конфигурации журнала (logback.xml, log4j.свойства, или что у вас есть) внутри файла JAR. Весь смысл даже иметь файл конфигурации ведения журнала - облегчить конечному пользователю настройку уровней ведения журнала путем редактирования файла. Хоронить его в архиве не имеет смысла, потому что для изменения уровня ведения журнала пользователь должен развернуть архив, отредактировать файл, а затем повторно упаковать архив.

вот мой любимый макет развернутого приложения. Это немного больше работы для настройки, но IMO стоит того, потому что это дает вам гибкость и простоту конфигурации, которую не делает uberjar.

my-app/
  bin/
    run-app.sh
  config/
    logback.xml
  lib/
    my-lib.jar
    my-app.jar

код run-app.sh скрипт будет выглядеть так:

BIN=`dirname ""`
BASE=$BIN/..
java -cp "$BASE/config:$BASE/lib/*" my-app.main

это имеет то преимущество, что, помещая каталог config в переднюю часть пути к классам, любой файл конфигурации журнала, найденный там, должен иметь приоритет над всем, что может быть найдено в одной из банок (например, включена сторонней библиотекой, над которой у вас нет контроля).


в случае базовый является библиотекой, она не должна поставляться с logback.XML. Почему библиотека беспокоится о регистрации? В случае, если это приложение, вы, вероятно, должны извлечь общую часть в библиотеку -base-common - и небольшое приложение -base-app. Тогда base-common не содержит никакой конфигурации logback. base-app и вывести как зависит base-common. Они могут укажите их конфигурацию logback без конфликта.


Я хотел ответить на свой собственный вопрос, потому что я специально спрашивал в контексте Clojure (хотя я совершенно не упомянул об этом в исходном вопросе, genius).

я исправил проблему, сделав так, как предлагает Алекс (принятый ответ), и положив свой logback.xml в собственном специальном каталоге dev-config. Затем я использую clojure project.clj файл, чтобы указать, что dev-config следует загружать только при запуске профиля разработки следующим образом:

;; project.clj
(defproject com.samedhi/base.app "0.0.1-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.5.1"]]
  :profiles {:dev {:source-paths ["dev", "dev-config"]}}
  :min-lein-version "2.0.0"
  :source-paths ["app/src" "app/templates"]
  :resource-paths ["config"]
  :target-path "out/"
  :compiler-options {:externs ["app/externs/base.js"]}
  :aliases {"dumbrepl" ["trampoline" "run" "-m" "clojure.main/main"]})

только важным моментом является то, что : профили =>: dev =>: source-paths был добавлен" dev-config " в его вектор. Этот каталог выбирается, когда я делаю локальную разработку, но не является частью созданных файлов jar и как таковой не отображается в других проектах, которые импортируют этот проект. Таким образом, журнал отображается при разработке этого проекта, но не отображается при использовании этого проекта другими проектами. Отлично.


Я нашел стратегию Алекса эффективной. Я хотел бы добавить небольшую подсказку: вы можете создать проект common-config с помощью редактировать общие файлы конфигурации положить внутрь (например, logback.XML и т. д.) Добавьте полученный артефакт как зависимость во все ваши проекты, с областью предоставил.

Это позволит вам использовать logback.xml во время компиляции/тестирования (из Eclipse или любой другой IDE), но исключит jar common-config из зависимости, доступные для наследования. Во время выполнения вы предоставите правильный файл (в зависимости от среды dev/test/prod), как показывает Alex.