2012-08-29 30 views
6

Tengo un proyecto A con log4j.jar en su ruta de compilación. Tengo un número de clases que tienen las declaraciones de registro en forma de:¿Cómo configuro log4j logging para un jar?

Logger _log = Logger.getLogger(A.<>.class); 
... 
_log.info("..."); 

estoy exportar el proyecto como un frasco en otro proyecto B. Proyecto B ya tiene su propio tarro de log4j y del fichero de configuración propia .xml . Quiero configurar clases particulares de A para iniciar sesión en la consola Apender en diferentes "niveles". ¿Cómo hago esto, por favor?

Respuesta

1

Bueno, básicamente, no deberías hacer eso. Piénselo de esta manera: si eso se hiciera de esa manera, cada biblioteca que se incluye en cualquier aplicación alojaría su propia configuración de registro, potencialmente anulando cualquiera de las que están en la aplicación, y entre sí, en un orden no especificado . No querrías eso. Entonces no.

[En caso de que realmente desee hacerlo, podría tener un archivo de propiedades en el contenedor que podría ser reemplazado por un archivo xml en la aplicación principal. Ver detalles here. Pero no lo hagas :)]

1

En general, no es así. En general, desea tener un archivo de configuración log4j. Pero supongo que puede cargar su configuración explícitamente desde su código, como se describe en the log4j documentation

1

Elija una versión de log4j.jar, probablemente la más nueva. Solo puedes usar una versión. Necesita fusionar la configuración de registro del proyecto A y del proyecto B. Podría hacer esto en las clases log4j en tiempo de ejecución, pero no es así. Solo muerde la bala y combínalos una vez en control de fuente.

+0

Ya veo. Entonces, agregar un registrador para com.A. algo funcionará bien en el archivo de configuración de B aunque A esté empaquetado en un contenedor. – mvd

+0

Sí. Pero ya no deberías tratar la configuración de registro como B. Pertenece a toda la aplicación. Piense en la configuración dentro de B como predeterminada para anular o reemplazar por completo. En qué jar están las clases no tiene relevancia para la configuración de registro que se aplica. Simplemente están empaquetados juntos. Log4j puede leer su archivo de configuración desde classpath y Java encuentra clases en classpath. Poner ambos en el mismo recipiente es simplemente conveniente. –

Cuestiones relacionadas