Pregunta

Tengo un oído con estructuras como:

APP.ear 
- APP1.war
    - WEB-INF/classes/log4j.properties
- APP2.war
    - WEB-INF/classes/log4j.properties
- app1-ejb.jar
- app2-ejb.jar
- log4j.jar
- spring.jar
- commons-lang.jar (...and other jar)

deseo que cada GUERRA tenga su propio registro de aplicación. Pero parece que la configuración anterior no funciona. Entrar para APP1 y APP2 va al registro de APP1. ¿Hay alguna forma para crear registros de aplicaciones separadas?

¿Fue útil?

Solución

Resulta que es imposible debido al cargador de clases. La jerarquía del cargador de clases es como:

cargador de clases de aplicaciones -> Ejb cargador de clases -> cargador de clase de guerra

Para tener un registro sepearte para la guerra individual, uno puede poner log4j.jar dentro de la guerra y dejar que el log4j utiliza el cargador de clase de guerra. Pero ya que tanto app1-ejb.jar y app2-ebj.jar también necesitan usar log4j, la log4j.jar sólo puede ser colocado en el nivel superior. Por lo que el log4j está en el nivel de aplicación del cargador de clases.

Puedo especificar una única configuración de log4j para registrar paquete diferente a diferentes archivos. Pero para la biblioteca común como la primavera, el registro no puede ser sepearted.

Otros consejos

La razón de que no funcionó porque el log4j está presente en la ubicación de la raíz, en lugar dejar que cada guerra tener un log4j.jar en su directorio WEB-INF / lib y quitar el log4j.jar de la raíz.

Para obtener más información acerca de la referencia a mi artículo de blog en este http://techcrawler.wordpress.com/

También puede hacer que al cambiar dinámicamente la propiedad del archivo en el archivo de propiedades utilizando el PropertyConfigurator en el código.

Logback es una solución viable para hacer frente a este problema. Después de tener mirada en torno a diferentes hacks para hacer este trabajo con log4j, hemos decidido cambiar a Logback. He utilizado la siguiente configuración con Logback frasco dentro de la aplicación de web.

Un archivo Logback dentro de la aplicación de web, que incluyen un archivo externo:

    <?xml version="1.0" encoding="UTF-8" ?>
    <configuration scan="true" scanPeriod="10 seconds">
        <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
            <resetJUL>true</resetJUL>
        </contextListener>

        <contextName>${project.artifactId}</contextName>

        <jmxConfigurator />

        <include file="${logback.configuration.filepath}" />
    </configuration>

${logback.configuration.filepath} se sustituye durante el filtrado Maven por la ruta exacta, externo a la aplicación de web del archivo de configuración (algo así como /opt/server/conf/loback.included.conf ).

Y a continuación, el contenido de la logback.included.conf (este archivo es parte de la projetct, entregado con build-helper:attach-artifact, por lo ${project.artifactId} también se sustituye durante el filtrado Maven):

    <?xml version="1.0" encoding="UTF-8" ?>
    <included>
        <appender name="file" class="ch.qos.logback.core.FileAppender">
            <file>/var/log/server/${project.artifactId}.log</file>
            <encoder>
                <pattern>[@/%contextName] %date{ISO8601} [%-5level] %thread:[%logger] %msg%n</pattern>
            </encoder>
        </appender>

        <root level="INFO">
            <appender-ref ref="file" />
        </root>
    </included>

Sólo limitación, el contenido del archivo incluido debe ser compatible con el de la Includer. Sólo escribir reglas de hecho.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top