Obteniendo jar en tomcat/shared/lib para iniciar sesión usando la configuración de la aplicación web llamándolos

Question

Estoy buscando actualizar nuestra instancia tomcat de 5.5.27 a 6.0.32 y estoy teniendo algunos problemas con el registro de jar en el directorio shared/lib (he creado este directorio en tomcat 6).

Tenemos un archivo jar que creamos como parte de nuestro proceso de compilación con algún código común en él y bajo Tomcat 5 esto vivió en shared/lib. Cuando escribimos las instrucciones de registro del código en este archivo jar, se escribieron en el archivo de registro de la aplicación web que llama al contenedor en ese momento. Cada uno de nuestros webapps tiene un log4j.properites y log4j.jar en su directorio WEB-INF/lib, y también había un log4j.jar en shared/lib, pero no log4j/properties.

Estamos utilizando log4j y obtener referencias a los registros de la siguiente manera:

import org.apache.commons.logging.Log; 
import org.apache.commons.logging.LogFactory;  
public class MyClass { 
    private final static Log CLASS_LOG = LogFactory.getLog(MyClass.class); 
} 

Pero cuando muevo la misma configuración exacta de nuestros tarros, aplicaciones web, log4.properties y log4j.jars en Tomcat 6, el las declaraciones de registro de nuestro contenedor común solo van a catalina.log.

He leído bastante (incluso http://www.mulesoft.com/tomcat-classpath y el cargador de clases y documentos de registro en el sitio web de tomcat) y sobre todo no puedo entender cómo funcionaba de la forma en que lo hizo en tomcat 5. (No lo configuré, es algo que he heredado y que hasta ahora 'ha funcionado').

¿Alguien tiene alguna experiencia similar al tratar de obtener registros de libs compartidas en archivos de registro de aplicaciones web? Estoy pensando que poner el contenedor compartido en el directorio WEB-INF/lib de cada webapp ordenaría esto, pero luego terminaría con muchas copias de la misma cosa.

Answer 1

Eche un vistazo a tomcat/conf/catalina.properties en tomcat6/7. Desaprobaron las rutas compartidas y del servidor, solo la ruta común está explícitamente configurada (por ejemplo, tomcat6/lib es común). Puede volver a habilitar compartido y supongo que obtendría una experiencia similar a la de Tomcat 5.x.

Sin embargo, ha dicho que está poniendo logging.properties en WEB-INF/lib. No creo que sea correcto, ya que solo debería contener archivos jar. Debería ir en WEB-INF/classes/

Además, en este momento, deje de usar el registro de commons. En su lugar codifique a slf4j, ya que tiene menos problemas de tomcat. Además, si utiliza logback en lugar de log4j, evita incluso tener que usar un adaptador (por ejemplo, sus llamadas slf4j son en realidad llamadas de logback directo). Utiliza un archivo de configuración diferente (pero hay conversores log4j.property en línea).

Answer 2

Si está utilizando Logback, http://logback.qos.ch/manual/contextSelector.html puede hacer lo que quiera.

Answer 3

No sé exactamente cómo está configurado el cargador de clases de tomcat. Con nuestro servidor de aplicaciones websphere tuvimos el mismo problema y tuvimos que reconfigurar el cargador de clases para cargar "parent last".

Esto significa que la búsqueda de archivos de configuración y libs primero en las carpetas de la aplicación y solo después de que no encuentre los recursos requeridos, carga la configuración del servidor web.

Quizás ese sea el caso y el 5.x de tomcat se configuró de esa manera.