Pytanie Jak wyłączyć odziedziczony plik logback.xml projektów (2 logback.xml w jednym projekcie)?


Mam projekt com.samedhi / base który ma logback.xml plik i projekt com.samedhi / derive to także ma logback.xml plik. Projekt 'czerpać"ma zależność od"baza". Kiedy ja "lein trampoline repl"na"czerpać", Otrzymuję następujące ostrzeżenie.

....
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
....

Tak więc wydaje się, że mam dwa logback.xml w mojej ścieżce klas. Co mam zrobić, aby "przetłumaczyć" plik logback.xml z projektu?baza"kiedy lein zastępuję od"czerpać' projekt?


21
2017-08-15 22:46


pochodzenie


W moim przypadku chcę utworzyć ogólną bibliotekę rejestrowania, której mój zespół używa we wszystkich projektach, dlatego chcę, aby mój plik logback.xml był pochowany w zależności od naszego logowania. - Catfish


Odpowiedzi:


O ile mi wiadomo, nigdy nie powinieneś pakować pliku konfiguracyjnego rejestrowania (logback.xml, log4j.properties lub co masz) wewnątrz pliku JAR. Cały punkt posiadania nawet pliku konfiguracyjnego rejestrowania ma ułatwić użytkownikowi końcowemu dostosowanie poziomów rejestrowania poprzez edycję pliku. Pogrzebanie go w archiwum jest sprzeczne z celem tego, ponieważ aby zmienić poziom rejestrowania, użytkownik musi rozwinąć archiwum, edytować plik, a następnie ponownie spakować archiwum.

Oto mój preferowany układ dla wdrożonej aplikacji. Trochę więcej pracy do skonfigurowania, ale IMO jest warte problemów, ponieważ daje elastyczność i łatwość konfiguracji, której nie ma uberjar.

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

Twój run-app.sh skrypt wyglądałby tak:

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

Ma to tę zaletę, że poprzez umieszczenie katalogu config na początku ścieżki klasy, każdy znajdujący się tam plik konfiguracji rejestrowania powinien mieć pierwszeństwo przed wszystkim, co można znaleźć w jednym z JARów (np. Dołączonym przez bibliotekę strony trzeciej, którą posiadasz brak kontroli).


17
2017-08-16 14:41



+1 dla ogólnego zalecenia, aby nie pakować pliku konfiguracji rejestrowania w słoiku. Jedyny czas, w którym robimy pakowanie pliku rejestrowania, to tworzenie pliku wykonywalnego słoika lub publikacja webstart java. Jednak, jak używamy maven, musimy zrobić kolejne mvn clean install aby usunąć słoik z konfiguracją rejestrowania z lokalnego repozytorium. - amaidment


W przypadku baza jest biblioteką, do której nie powinien należeć plik logback.xml. Dlaczego biblioteka jest zaniepokojona rejestrowaniem? Jeśli jest to aplikacja, prawdopodobnie wyodrębnij część wspólną do biblioteki - base-common - i mała aplikacja - baza-aplikacja. Następnie base-common nie zawiera żadnej konfiguracji logback. baza-aplikacja i czerpać oba zależą od base-common. Mogą określić swoją konfigurację logback bez konfliktu.


4
2017-08-16 05:52





Chciałem odpowiedzieć na moje własne pytanie, ponieważ konkretnie pytałem w kontekście Clojure (chociaż zupełnie nie wspomniałem o tym w pytaniu rodzącym, geniuszu).

Naprawiłem problem, sugerując Alex (zaakceptowana odpowiedź) i umieszczając plik logback.xml w specjalnym katalogu dev-config. Następnie używam clojure's project.clj plik, aby to określić dev-config powinien być ładowany tylko podczas uruchamiania profilu programistycznego, jak poniżej:

;; 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"]})

Jedynym ważnym punktem jest to, że : profiles =>: dev =>: source-paths do swojego wektora dodano "dev-config". Katalog ten jest pobierany podczas tworzenia lokalnego oprogramowania, ale nie jest częścią utworzonych plików jar i jako taki nie pojawia się w innych projektach, które importują ten projekt. Tak więc rejestracja pojawia się podczas wykonywania projektu, ale nie pojawia się, gdy projekt jest wykorzystywany przez inne projekty. Doskonały.


1
2017-08-17 19:30





Uważam, że strategia Alexa jest skuteczna. Chciałbym dodać małą podpowiedź: można utworzyć projekt common-config z edytowalne wspólne pliki konfiguracyjne umieścić wewnątrz (np. logback.xml itd.) Dodaj powstały artefakt jako zależność we wszystkich projektach wraz z zakresem opatrzony.

Umożliwi to użycie logback.xml w czasie kompilacji / testu (z Eclipse lub jakiegokolwiek innego IDE), ale wykluczy słoik common-config z zależności dostępnych dla dziedziczenia. W czasie działania zapewnisz odpowiedni plik (w zależności od środowiska dev / test / prod), jak pokazuje Alex.


0
2017-08-01 14:58