2009-06-16 14 views
5

Tengo algunos archivos jar que se distribuirán a los clientes que están utilizando log4j para el registro. Mi pregunta es: ¿debo incluir una configuración de log4j.xml en el archivo jar o hacer que el cliente proporcione uno si desean iniciar sesión?log4j.xml en tarros de cliente

Mi sensación es dejar el fichero de configuración log4j.xml cabo de los frascos de los clientes, ya que los archivos jar apache todos vienen con el registro de log4j, pero sans log4j.xml.

Respuesta

9

Sí, déjalo fuera. Es una molestia total cuando se ignora su archivo de configuración log4j porque una de las 60 bibliotecas de terceros de su aplicación contiene las suyas.

0

Si está utilizando log4j en su aplicación, debe incluirlo en su proyecto. Si no lo eres, ¿por qué lo pondrías allí? ¿Qué pasa si el cliente A quiere log4j versión 1.2 y el cliente B quiere log4j versión 1.3.

Decídales a decidir qué necesitan para sus proyectos y preocúpese por lo que necesita para los suyos.

+0

Probablemente se esté refiriendo a la dependencia actual de log4j.jar, pero estoy hablando del archivo de configuración log4j.xml. –

+0

Ahh sí, lo siento, me lo perdí. Tengo un proyecto aquí que tiene una dependencia para este archivo jar ABIS. Este archivo jar ABIS tiene su propio archivo de configuración log4j.xml. A veces, los parámetros del log4j se sobreescriben con los del jar ABIS importado (el nivel de registro se establece en ERROR en lugar del DEPURADOR en el que tengo el conjunto de minas). Definitivamente lo dejaría afuera y dejaría que el cliente estableciera el suyo. – amischiefr

5

Lo bueno de log4j en su caso es que su contenedor no debería tener que preocuparse por ello. El caso de uso básico de log4j es:

  1. obtener un objeto registrador para la clase actual
  2. Llame a uno de los métodos en ese registrador, como debug("some message");

Si los frascos que está enviando son para ser utilizado por una aplicación más grande, entonces idealmente su código solo hará los dos pasos enumerados anteriormente. De esta forma, su código simplemente obtendrá objetos de registrador de la instancia de log4j ya configurada en la aplicación del cliente. Su código de producción se desacopla de tener que saber cómo configurar log4j.

Cualquier registro que necesite ver para su desarrollo de las jarras se puede lograr configurando una instancia de log4j en métodos unit test setUp() o algo similar que no se combinará con el código de producción que va al cliente.

0

Agregaría la configuración xml y la cargaría con instrucciones para el usuario mostrando diferentes configuraciones y opciones. Esto hará que sea más fácil para ellos o para el soporte habilitar el registro de adición.

+0

esto obliga al cliente a editar el contenido de mi archivo jar. No estoy seguro de llamar a eso una mejor práctica. –

2

Pondré una configuración predeterminada de log4j que usted espera sea útil para sus clientes en la documentación. De esta forma, las personas interesadas pueden ver qué opciones de registro tiene (por lo general, ciertas clases tienen mensajes de registro más interesantes, desde la perspectiva del usuario). Me resulta molesto cuando tengo una lib de terceros usando log4j y no tiene documentación, y hay mensajes de registro llenando mi pantalla y tengo que tratar de descubrir cómo habilitar o suprimir ciertos mensajes de registro.

Cuestiones relacionadas