Error ClassNotFoundException en Tomcat 5.5 y Tomcat 6.0

Question

Tengo este extraño problema con los servidores tomcat 5.5 y tomcat 6.0. Tengo dos aplicaciones web que se instalarán en Tomcat. Cuando se inicia Tomcat, estas dos aplicaciones web también se inician simultáneamente, pero a veces una aplicación web no se inicializa debido a la falla de inicio en una aplicación, otra aplicación está obteniendo errores de clase avanzada durante la ejecución. En Tomcat 7.0, la aplicación se ejecuta correctamente incluso si la otra aplicación no se pudo inicializar.

Después de algunas depuraciones, llegué a saber que hay un contenedor llamado crystal.jar que se encuentra en la carpeta web-inf/lib de ambas aplicaciones. He movido el contenedor a la carpeta common/lib de tomcat y luego comenzó a funcionar bien. Quiero saber por qué funciona bien en tomcat 7.0 no en las versiones tomcat 5.x y tomcat 6.x. ¿Hay algún cambio en la arquitectura de carga de clases entre estas versiones?

Gracias

EDIT1: La biblioteca estaba en la ubicación del directorio de aplicaciones tanto en el WEB-INF \ lib y no tienen ninguna dependencia con los archivos DLL externa. Acabo de leer acerca de la arquitectura del cargador de clases Tomcat 5.5 y me di cuenta de que cada aplicación web tiene su propio cargador de clases. Las bibliotecas de la carpeta WEB-INF \ lib y la carpeta de clases se cargarán en este cargador de clases. Las bibliotecas, cualquiera que esté almacenada en el directorio común, se colocarán en un cargador de clases compartido. Entonces esta biblioteca debe cargarse por separado en el cargador de clases separado de la aplicación web. Incluso si una aplicación web no puede iniciarse, otra aplicación web debería funcionar de manera independiente. Es por eso que me sentí extraño y necesito investigar Furthur.

Answer 1

finalmente encontró la respuesta para este problema

Existe una clase conocida de las pérdidas de memoria PermGen, cuando una clase de biblioteca hace referencia a una clase de sistema y así vive más allá de su edad. Un ejemplo es cuando Java descubre un controlador JDBC o algún otro servicio y lo "registra automáticamente". Mantiene referencia en un sistema , pero la clase en sí pertenece a la aplicación web y tiene que descargarse cuando la aplicación se detiene, pero no puede, debido a esa referencia . No todas estas referencias son fáciles de borrar.

Un síntoma típico en este caso es que la primera aplicación web que se basa en esta característica del sistema tendrá éxito, pero el segundo y otros fallará (porque el servicio que está registrado en el sistema pertenece a la primera aplicación web y no puede ver las clases del cargador de clases de la segunda aplicación y viceversa).

Tomcat 7 y las versiones más recientes de Tomcat 6 tienen una mejor protección frente a ciertas pérdidas conocidas de memoria PermGen en su configuración predeterminada de .

Tomcat 5.5 no tiene tal protección en absoluto.

EDITAR Unas referencias

http://people.apache.org/~markt/presentations/2010-08-05-Memory-Leaks-JavaOne-60mins.pdf http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

http://eclipse.org/mat/

http://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics http://wiki.apache.org/tomcat/MemoryLeakProtection