как подавить унаследованный 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.