プロジェクトcom.samedhi/baseにlogback.xmlファイルがあり、プロジェクトcom.samedhi/derivにもlogback.xmlファイル。プロジェクト 'derive'は 'base'に依存しています。私が「lein trampoline repl
"on 'derive'、次の警告が表示されます。
....
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
....
したがって、問題は、クラスパスに2つのlogback.xmlがあることであるように見えます。 'derive'プロジェクトからreplを実行するときに、プロジェクト 'base'からlogback.xmlを「抑制する」にはどうすればよいですか?
私に関する限り、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
スクリプトは次のようになります。
BIN=`dirname "$0"`
BASE=$BIN/..
Java -cp "$BASE/config:$BASE/lib/*" my-app.main
これには、構成ディレクトリをクラスパスの前に配置することにより、そこにあるログ構成ファイルが、JARの1つにあるもの(たとえば、既存のサードパーティライブラリに含まれているもの)よりも優先されるという利点があります。制御できません)。
baseがライブラリの場合、logback.xmlは付属していません。なぜ図書館は伐採を懸念しているのですか?アプリケーションの場合は、共通部分をライブラリに抽出する必要があります– base-common –そして小さなアプリケーション– base-app。その場合、base-commonにはログバック構成が含まれません。 base-appとderiveはどちらもbase-commonに依存します。競合することなくログバック構成を指定できます。
私は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ファイルの一部ではないため、このプロジェクトをインポートする他のプロジェクトには表示されません。したがって、このプロジェクトで開発を行うとログは表示されますが、このプロジェクトが他のプロジェクトで使用されている場合は表示されません。優秀な。
アレックスの戦略が効果的であることがわかりました。小さなヒントを追加したいと思います。編集可能な共通構成ファイルを内部に配置してcommon-configプロジェクトを作成できます(例:logback.xmlなど)。結果のアーティファクトを依存関係としてすべてのプロジェクト、スコープ提供。
これにより、コンパイル/テスト時に(Eclipseまたはその他のIDEから)logback.xmlを使用できるようになりますが、継承に使用できる依存関係からcommon-configjarが除外されます。 Alexが示すように、実行時に適切なファイルを提供します(dev/test/prod環境によって異なります)。
私の場合、Stephenからの回答を変更したので、project.clj
は次のようになります。
:profiles {:dev {:resource-paths ["test/resources"]}} ; appended to default
新しいディレクトリtest/resources
には、ライブラリのテストに使用されるlogback.xml
が含まれていますが、ライブラリのユーザーには伝達されません。
コメントによると、"test/resources"
のデフォルト値に:resources-paths
が追加され、["resources" "test/resources"]
の最終値が作成されることに注意してください。