logging - ¿Cómo suprimo un archivo logback.xml de proyectos heredados(2 logback.xml en un solo proyecto)?

clojure leiningen

Question

Tengo el proyecto com.samedhi / base que tiene un archivo logback.xml y el proyecto com.samedhi / derive que también tiene un archivo logback.xml . El proyecto '' derive '' tiene una dependencia en '' base ''. Cuando " lein trampoline repl " en '' derive '', aparece la siguiente advertencia.

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

Entonces, el problema parece ser que tengo dos logback.xml en mi classpath. ¿Qué se supone que debo hacer para "suprimir" el logback.xml desde el proyecto '' base '' cuando me respondo desde el proyecto '' derivar ''?

Answer 1

En caso de que la base sea ​​una biblioteca, no debería venir con un logback.xml. ¿Por qué una biblioteca está preocupada por el registro? En caso de que sea una aplicación, probablemente debería extraer la parte común en una biblioteca ( base-common ) y una pequeña aplicación ( base-app) . Entonces la base común no contiene ninguna configuración de retroceso. La aplicación base y la derivada dependen de la base común . Pueden especificar su configuración logback sin conflicto.

Answer 2

En lo que a mí respecta, nunca debe empaquetar un archivo de configuración de registro (logback.xml, log4j.properties, o lo que tenga) dentro de un archivo JAR. El objetivo de tener un archivo de configuración de registro es facilitar que el usuario final ajuste los niveles de registro editando el archivo. Al enterrarlo en un archivo se pierde el propósito de eso, porque para cambiar el nivel de registro, el usuario debe expandir el archivo, editarlo y luego volver a empaquetarlo.

Aquí está mi diseño preferido para una aplicación implementada. Es un poco más de trabajo para configurar, pero IMO vale la pena porque le ofrece la flexibilidad y la facilidad de configuración que no hace un uberjar.

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

Su script run-app.sh se vería algo así como:

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

Esto tiene la ventaja de que, al colocar el directorio de configuración en la parte delantera de la ruta de clase, cualquier archivo de configuración de registro que se encuentre allí debe tener prioridad sobre cualquier cosa que pueda encontrarse en uno de los JAR (por ejemplo, incluido en una biblioteca de terceros). no hay control sobre).

Answer 3

Encontré la estrategia de Alex para ser efectiva. Me gustaría agregar una pequeña pista: puede crear un proyecto de configuración común con los archivos de configuración comunes editables incluidos (por ejemplo, logback.xml, etc.). Agregue el artefacto resultante como una dependencia en todos sus proyectos, con el alcance proporcionado .

Esto le permitirá utilizar el logback.xml en el momento de compilación / prueba (de Eclipse o cualquier IDE), pero excluirá el archivo de configuración común de las dependencias disponibles para la herencia. En el tiempo de ejecución, proporcionará el archivo adecuado (según el entorno dev / test / prod) como muestra Alex.

Answer 4

Quería responder a mi propia pregunta porque estaba preguntando específicamente en el contexto de Clojure (aunque no lo mencioné por completo en la pregunta original, genio).

Arreglé el problema haciendo lo que Alex (respuesta aceptada) sugiere, y poniendo mi logback.xml en su propio directorio especial dev-config . Luego uso el archivo project.clj de clojure para especificar que dev-config solo se debe cargar cuando se ejecuta el perfil de desarrollo, de la siguiente manera:

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

El único punto importante es que : profiles =>: dev =>: source-paths ha agregado "dev-config" a su vector. Este directorio se selecciona cuando estoy haciendo desarrollo local, pero no forma parte de los archivos jar creados, y como tal no aparece en otros proyectos que importan este proyecto. Por lo tanto, el registro se muestra cuando se realiza el desarrollo de este proyecto, pero no se muestra cuando este proyecto es utilizado por otros proyectos. Excelente.