Как я могу подавить унаследованные проекты logback.xml файл (2 logback.xml в одном проекте)?
У меня есть проект com.samedhi/base, у которого есть файл logback.xml и проект com.samedhi/derive, который также имеет logback.xml. Проект выводить 'имеет зависимость от базы. Когда "lein trampoline repl
" на " вывести", я получаю следующее предупреждение.
....
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 в моем пути к классам. Что я должен делать, чтобы "приказать" logback.xml из проекта base, когда я нахожусь в реплике из проекта getive?
Ответы
Ответ 1
Насколько мне известно, вы никогда не должны упаковывать в файл JAR файл конфигурации журнала (logback.xml, log4j.properties или что у вас есть). Весь смысл даже иметь конфигурационный файл журнала - это облегчить для конечного пользователя корректировку уровней ведения журнала путем редактирования файла. Похоронить его в архив нарушает цель этого, потому что для изменения уровня ведения журнала ваш пользователь должен расширить архив, отредактировать файл, а затем повторно упаковать архив.
Вот мой предпочтительный макет для развернутого приложения. Это немного больше работы по настройке, но IMO стоит того, потому что это дает вам гибкость и простоту настройки, которые нет в uberjar.
my-app/
bin/
run-app.sh
config/
logback.xml
lib/
my-lib.jar
my-app.jar
Ваш run-app.sh
script будет выглядеть примерно так:
BIN=`dirname "$0"`
BASE=$BIN/..
java -cp "$BASE/config:$BASE/lib/*" my-app.main
Это имеет то преимущество, что, помещая каталог конфигурации в начале пути к классам, любой найденный там файл конфигурации журналов должен иметь приоритет над всем, что может быть найдено в одном из JAR (например, включенным сторонней библиотекой что у вас нет контроля).
Ответ 2
В случае, если base является библиотекой, она не должна содержать logback.xml. Почему библиотека связана с протоколированием? В случае, если это приложение, вы должны, вероятно, извлечь общую часть в библиотеку - base-common - и небольшое приложение - базовое приложение. Тогда base-common не содержит конфигурацию журнала. base-app и вывод зависят от базового. Они могут указывать конфигурацию журнала без конфликтов.
Ответ 3
Я хотел ответить на свой вопрос, потому что я специально спрашивал в контексте Clojure (хотя я полностью не упомянул об этом, исходя из вопроса, гения).
Я исправил проблему, выполнив предложение Alex (принятый ответ) и поместив свой файл 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"]})
Единственным важным моментом является то, что : profiles = > : dev = > : source-paths добавил к своему вектору "dev-config". Этот каталог подбирается, когда я занимаюсь локальной разработкой, но не является частью созданных файлов jar и, как таковой, не отображается в других проектах, которые импортируют этот проект. Таким образом, журнал регистрации появляется при разработке этого проекта, но не отображается, когда этот проект используется другими проектами. Отлично.
Ответ 4
Я нашел стратегию Алекса эффективной. Я хотел бы добавить небольшой намек: вы можете создать проект common-config с редактируемыми общедоступными файлами конфигурации, помещенными внутри (например, logback.xml и т.д.). Добавить полученный артефакт как зависимость во всех ваших проектах с предоставленной областью.
Это позволит вам использовать logback.xml во время компиляции/тестирования (из Eclipse или любой другой IDE), но исключает банку common-config из зависимостей, доступных для наследования. Во время выполнения вы предоставите правильный файл (в зависимости от среды dev/test/prod), как показывает Алекс.
Ответ 5
В моем случае я изменил ответ стивена, поэтому project.clj
выглядит так:
:profiles {:dev {:resource-paths ["test/resources"]}} ; appended to default
и новый каталог test/resources
содержит logback.xml
, используемый для тестирования библиотеки, но он не распространяется для пользователей библиотеки.
Обратите внимание, что согласно комментарию "test/resources"
добавляется к значению по умолчанию :resources-paths
, чтобы создать окончательное значение ["resources" "test/resources"]