2008-11-06 11 views

Respuesta

37

Como puede ver here, Tomcat crea un cargador de clases por aplicación web en su servidor. Por lo tanto, si tiene webapp1 y webapp2 que comparten la misma biblioteca, esta biblioteca se cargará dos veces.

Eventualmente puede colocar esta biblioteca en el directorio común (tomcat-dir/common/lib) si es compartida por todos los webapps que se ejecutan en su servidor Tomcat.

+1

No tengo un directorio común en el interior del servidor, sólo tener clases y directorio lib. ¿Debo crear uno común dentro? –

+0

He editado mi publicación para indicar que el buen directorio para usar es [tomcat-installation-directory]/common/lib – romaintaz

+0

aparentemente está bien [y se recomienda] implementar controladores jdbc para compartir FWIW http://stackoverflow.com/questions/ 6981564/why-jdbc-driver-must-been-put-in-tomcat-home-lib-folder] – rogerdpack

6

De la experiencia: las dos aplicaciones web están completamente aisladas entre sí - las bibliotecas para una no se utilizan en otra - por lo tanto, para responder a su pregunta inicial - sí, se cargarían dos veces.

Para contestar la segunda pregunta, si debe implementar estas bibliotecas en el directorio compartido de Tomcat - Yo diría que no, y aquí es por qué:

Si implementa un tarro biblioteca en la ubicación compartida (Tomcat/server/lib), entonces esa versión de la biblioteca se convierte en la predeterminada para todas las aplicaciones web que se ejecutan bajo esa instancia de Tomcat. Como puede ver en this overview of the tomcat architecture, el cargador de clases funciona "por cadena", siendo la carpeta de lib de la aplicación web individual el último lugar donde se verá antes de arrojar una excepción de clase no encontrada. Esto no es cierto en Tomcat 6 y Tomcat 7: cualquier clase en la carpeta de aplicaciones web lib y clases será resuelto antes que en común, y por lo tanto, esto no romperá otras aplicaciones que implementan todos sus jarrones en la guerra 2 .

El problema, por lo tanto, de implementar una biblioteca compartida en ese directorio es que rompe la arquitectura de las aplicaciones individuales que se aíslan unas de otras. Está bien en su ejemplo inicial, pero si desea implementar una aplicación de terceros (por ejemplo, si ejecuta una aplicación que consume Portlet para manejar contenido específico), se ejecuta al instante en los problemas de dependencia de la versión: su versión compartida de una biblioteca puede no es correcto para la aplicación de terceros, pero como el paquete ya está cargado, lanzará excepciones a la derecha y al centro.

+0

Pensé que funcionó "hasta la cadena" sin embargo? ¿También el enlace es para algún tipo de documento de pago? – rogerdpack

+0

Se ha eliminado el documento al que se refiere. ¿Podría actualizar o eliminar el enlace (descripción general de la arquitectura Tomcat)? – naXa

+0

@ steve-ash y ¿qué pasa con el orden de resolución en Tomcat 8 y Tomcat 9? ¿Es lo mismo que en Tomcat 7? – naXa

28

No recomendaría colocar los archivos jar en la carpeta compartida. Digamos, por ejemplo, que necesita en el futuro implementar una aplicación de terceros que tenga una versión más reciente de un archivo jar en la carpeta WEB-INF. Para esta aplicación, las clases del jar se cargarán dos veces (incluso si tienen los mismos nombres), una de la carpeta compartida y otra de la carpeta de la aplicación web. Esta situación puede causar errores muy difíciles de encontrar.

Si los archivos jar están en las carpetas de la aplicación web, se cargan por cargadores de clases separados y no interfieren entre sí.

+0

Estoy bastante de acuerdo. Colocar las bibliotecas en el directorio de recursos comunes puede ser peligroso, y debe usarse solo si puede controlar qué aplicaciones webapps se implementan y cuál es la versión de las bibliotecas utilizada para cada aplicación web ... – romaintaz

+0

¿Podría explicar cómo se cargan dos veces? ¿Los compartidos "anularán" los de la carpeta WEB-INF? – rogerdpack

+0

Es mejor tratar esta situación como "indefinida". Tendría dos instancias de la misma clase, cada una cargada por un cargador de clases diferente. Esto usualmente significa problemas. – kgiannakakis

5

Estamos usando tomcat6 y encontramos una buena manera de tener tomcat repleto de bibliotecas comunes que todas nuestras aplicaciones webapps necesitan.

Editar en conf/catalina.propiedades la entrada common.loader. P.ej. añadir una carpeta adicional con los tarros te gusta compartir

common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar, 
       ${catalina.home}/lib,${catalina.home}/lib/*.jar, 
       {catalina.home}/mylibs/*.jar 

a continuación, poner todas las bibliotecas comunes '' mylibs allí. Hecho.

¿Por qué comenzamos a usar una carpeta mylibs en lugar de WEB-INF/lib en todos los webapps (archivos WAR)?

¡El despliegue comenzó a ser una pesadilla después de que WAR cruzó la línea de los 50MB!

Al tener una aplicación web con una versión no frasco aún puede ponerlo en WEB-INF/lib sobrescribir lo que tiene en mylibs.

1

Si no desea que sus bibliotecas para cargar dos veces los ponen en:

  • Tomcat 6: $CATALINA_HOME/lib
  • Tomcat 5: $CATALINA_HOME/common/lib

(retirado de la pregunta y copiado aquí para que pueda ser votado/comentado)

+1

También puede personalizar catalina.properties para agregar su propio directorio personalizado al cargador de clases común. Esto es útil para segregar jarras Tomcat con jarras necesarias para sus aplicaciones. – JustinKSU

+1

No recomendaría esto: no debe mezclar sus archivos personalizados junto con los archivos de stock, porque no estará claro cuáles son suyos cuando aparezca alguien nuevo en el futuro. –

0

PermGen Space of heap se usa para sto re clases y metadatos sobre clases en Java.

java.lang.OutOfMemoryError error: PermGen espacio puede ocurrido con frecuencia porque estamos cargando un montón de biblioteca duplicado en Apache Tomcat puede alguien cuota de ello en detalles

Cuestiones relacionadas