come si sopprime un file logback.xml dei progetti ereditati (2 logback.xml in un singolo progetto)?

Question

devo progetto com.samedhi/base che dispone di un file dilogback.xml e progetto com.samedhi/derivano che ha anche un file dilogback.xml. Il progetto 'deriva' ha una dipendenza su 'base'. Quando "lein trampoline repl" su "deriva", viene visualizzato il seguente avviso.

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

Quindi, il problema sembra essere che ho due logback.xml del mio percorso di classe. Cosa dovrei fare per "sorvolare" il logback.xml dal progetto "base" quando sostituisco il progetto "derive"?

Answer 1

Per quanto mi riguarda, non si dovrebbe mai impacchettare un file di configurazione di registrazione (logback.xml, log4j.properties o cosa si ha) all'interno di un file JAR. L'intero punto di avere anche un file di configurazione della registrazione è quello di rendere più facile all'utente finale regolare i livelli di registrazione modificando il file. Seppellirlo in un archivio, lo scopo è lo stesso, perché per modificare il livello di registrazione l'utente deve espandere l'archivio, modificare il file e quindi ricopiare l'archivio.

Ecco il mio layout preferito per un'applicazione distribuita. È un po 'più di lavoro da impostare, ma IMO vale il problema perché ti dà la flessibilità e la facilità di configurazione che un uberjar non ha.

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

Lo script run-app.sh sarebbe simile:

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

Questo ha il vantaggio che, mettendo la directory di configurazione nella parte anteriore del classpath, qualsiasi file di registro di configurazione trovato ci dovrebbe avere la precedenza rispetto tutto ciò che può essere trovato in uno dei JAR (ad esempio, incluso da una libreria di terze parti su cui non si ha alcun controllo).

Answer 2

Nel caso in cui la base sia una libreria, non dovrebbe venire con un logback.xml. Perché una biblioteca è preoccupata per la registrazione? Nel caso si tratti di un'applicazione, è consigliabile estrarre la parte comune in una libreria - base-comune - e una piccola applicazione - base-app. Quindi base-comune non contiene alcuna configurazione di logback. base-app e derivano entrambi dipendono da base-comune. Possono specificare la loro configurazione di logback senza conflitti.

Answer 3

Volevo rispondere alla mia stessa domanda perché stavo chiedendo specificamente nel contesto di Clojure (anche se ho completamente omesso di menzionarlo nella questione originaria, geniale).

Ho risolto il problema facendo come suggerito Alex (risposta accettata) e inserendo il mio logback.xml nella propria directory speciale dev-config.Ho quindi utilizzare il file di clojure project.clj per specificare che dev-config devono essere caricati solo quando il profilo di sviluppo è gestito, come segue:

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

L'unico punto importante è che : profili =>: dev =>: fonte-percorsi ha aggiunto "dev-config" al suo vettore. Questa directory viene rilevata quando eseguo lo sviluppo locale, ma non fa parte dei file jar creati e in quanto tale non viene visualizzata in altri progetti che importano questo progetto. Pertanto, la registrazione viene visualizzata durante lo sviluppo di questo progetto, ma non viene visualizzata quando questo progetto viene utilizzato da altri progetti. Eccellente.

Answer 4

Ho trovato la strategia di Alex per essere efficace. Vorrei aggiungere un piccolo suggerimento: puoi creare un progetto di configurazione comune con i file di configurazione comuni modificabili messi (ad es. Logback.xml ecc.) Aggiungi l'artefatto risultante come dipendenza in tutti i tuoi progetti, con l'ambito fornito.

Ciò consentirà di utilizzare logback.xml in fase di compilazione/test (da Eclipse o da qualsiasi IDE), ma escluderà il vaso common-config dalle dipendenze disponibili per l'ereditarietà. In fase di esecuzione fornirai il file corretto (a seconda dell'ambiente di sviluppo/test/prod) mostrato da Alex.