Actualmente estoy trabajando en una aplicación que tiene alrededor de una década de antigüedad. Cuando busqué en los archivos jar que están asociados con la aplicación, puedo ver muchos frascos que no son necesarios y muchas versiones diferentes del mismo jar.Archivos jar no deseados en tomcat/lib o WEB-INF/lib
¿Cuáles son las desventajas de tener tarros no deseados en lib. ¿Cuál es la manera más fácil de encontrarlos y eliminarlos?
podría obtener problemas si un cargador de clases decide cargar las clases según las versiones del archivo jar de lo esperado. Este tipo de problemas suelen ser difíciles de rastrear. El servidor examinará los archivos jar en algún orden específico (alfabéticamente por nombre de archivo?) Y usará la primera clase/recurso coincidente que encuentre. Probablemente no haya garantías de que la versión más reciente de un archivo jar se vea primero.
No conozco ninguna herramienta que pueda descubrir qué frascos están sin usar. Eso puede ser imposible en general debido a la reflexión, pero un cierto grado de verificación automática debería ser posible, al menos en teoría.
Extracción archivo jar no utilizada por ensayo y error es problemático si usted no tiene buenas pruebas de unidad, lo cual dudo que tiene en sus décadas de aplicación de edad. Siempre puede haber algún caso raro de error que dependa solo de la versión anterior del paquete que acaba de eliminar.
Ok genial ... Gracias. – Umesh
Por archivos jar no deseados en su aplicación, ¿Quiere decir que éstos se generan como parte de su proceso de compilar y generar cada vez? Si es así, entonces podrían ser los scripts de compilación los que quiera limpiar.
Si se refiere al entorno de despliegue real, entonces cualquier limpieza debe hacerse con mucho cuidado. ¿Por qué no intentar comenzar de nuevo en un nuevo entorno de prueba con una instalación limpia de tomcat y los ejecutables de la última versión implementados? Vea si funciona bien solo con eso, y si lo hace, entonces tal vez los frascos adicionales sean de hecho innecesarios.
En cuanto a las desventajas, no veo ningún aparte del tamaño del archivo de la implementación.
lo que quise decir con jarras no deseadas es jtds1.2.jar y jtds1.2.2.jar es allí donde 1.2 no se usa. Estamos utilizando un tipo de conexión jtds durante los últimos seis meses. Pero todavía contiene el mssql.jar, etc. que antes se usaba. No se generan archivos como parte de la compilación/compilación. – Umesh
¿Cómo se puede decidir cuál de los frascos no se está en realidad utilizado?
Sugeriría hacer un cambio completo de QA. No tiene idea si el código elegido del conjunto de tarros sombreará una implementación errónea que emerge si elimina un contenedor "obsoleto".
Mi sugerencia es que si sus aplicaciones están funcionando, deje las jarras como están ahora. Sería muy problemático si no imposible de descubrir, qué archivos jar son realmente recogidos por el cargador de clases. (Por supuesto, no despliegue nuevas aplicaciones).
puede encontrar los paquetes que contiene un archivo JAR utilizando JarAnalyzer. Esto le dará una idea de los duplicados y puede comenzar a eliminar las versiones anteriores de los archivos jar. Sin embargo, este procedimiento debe hacerse a mano y por prueba y error. Además, el mismo paquete puede estar contenido en dos jarras con diferentes nombres y sin información de control de versiones.
Como ya he dicho, tener diferentes versiones de la misma jarra podría causar estragos. No puede saber qué versión se utilizará realmente y qué conflictos traerá a esta u otra aplicación. Es por eso que nunca debe usar la carpeta compartida de Tomcat para jar de aplicaciones. Si se encuentra en una situación en la que se colocan muchos archivos jar en la carpeta compartida, evite usar este servidor para nuevas aplicaciones.
Por ahora solo tengo una aplicación ejecutándose bajo el tomcat. Pero la razón para incluir jar en la ruta compartida de tomcat es que algunos archivos tomcat no se tomarán mientras residan en la aplicación lib. Ej: jtds.jar, mysql v 5.4 jar. Si coloca estos archivos jar en la aplicación lib e intenta conectarse a la base de datos, arrojará una excepción. (Nunca funcionó para mí. Para una solución, lo copié en tomcat lib y comenzó a funcionar.) – Umesh
Si está utilizando un recurso JNDI para configurar un origen de datos, entonces el conector jdbc debe estar en la carpeta compartida, de modo que el archivo jar está presente antes de que comience su aplicación. Esta es una excepción a la regla. No coloque frascos en la carpeta compartida, a menos que esto sea absolutamente necesario. – kgiannakakis
Creo que significaba "contras", no "crones". Lo sentimos, no hay privilegios de edición todavía. – DVK
cambiado! y todo lo mejor para obtenerlo pronto! – Umesh