java - org - slf4j-simple
Log4j 2.0 y SLF4J y el futuro interminable de los marcos de registro de Java (2)
Es una pregunta subjetiva.
Sugiero usar slf4j, ya que puede usar log4j como back-end si eso es lo que necesitas.
Es probable que utilice una cantidad de componentes que pueden usar diferentes API de registro. Es bueno poder consolidar la salida a través de esas API en una sola ruta de salida.
Me acabo de enterar hoy de que Log4J 2.0 se está desarrollando activamente, hay una versión alfa y se dice que reemplaza el logback.
En este momento en mi aplicación tengo cerca de 4 marcos de registro tal vez más:
- Registro Util de Java
- log4j
- slf4j
- logback (ignorado gracias a un truco provisto por maven)
- registro de commons (ignorado gracias a un truco provisto por maven)
- Y tomcat tiene su propio adaptador JULI
He estado usando log4j (1.2.x) porque francamente no he necesitado las características de los chicos más nuevos, pero últimamente he tenido la tentación de cambiar a SLF4J y principalmente porque no quiero tener que volver a escribir mis complicados archivos de configuraciones de log4j a un nuevo formato (logback).
Ahora mi pregunta es en términos de lo que debo codificar en contra de que SLF4J sea la elección correcta para el futuro dado log4j 2.0.
Parece que debería seguir con log4j viejo ( 1.2.x ) ya que es el denominador común más bajo?
ACTUALIZACIÓN: en un examen más detallado de log4j 2.0, aunque muy similar, parece que la configuración no es compatible con log4j 1.2. Parece que el logback es la mejor opción.
Descargo de responsabilidad : soy el fundador de los proyectos log4j, slf4j y logback pero no estoy asociado con log4j 2.0.
Según lo entiendo, a pesar de su nombre, log4j 2.0 es muy diferente de log4j 1.x. En lo que respecta a la API de usuario, log4j 2.0 es en gran medida incompatible con log4j 1.x. Log4j 2.0 proporciona una capa de adaptación para log4j 1.x que en este momento (2012-08) undocumented está undocumented .