En Autentia trabajamos constantemente en el desarrollo de aplicaciones web para nuestros clientes. En esta línea, resulta fundamental el manejo y dominio de los distintos servidores para aplicaciones web disponibles que ofrecen mayor fiabilidad. En este nuevo tutorial os queremos mostrar cómo configurar el ClassLoader para el WebSphere Server.
1. Configuración del ClassLoader
Recordemos que el ClassLoader es la pieza de la máquina virtual Java que se encarga de cargar una clase en memoria cuando hacemos referencia a ella en el código. Es decir, cuando hacemos un “new” de una clase, el ClassLoader es el encargado de localizar el .class correspondiente e instanciar el objeto en memoria.
En WebSphere 5.1 existe una única máquina virtual por servidor. Pero puede existir más de un ClassLoader por máquina virtual.
La siguiente tabla muestra como migrar la visibilidad de los módulos de las aplicaciones de la versión 4.0.x a sus equivalentes de la versión 5.x
|
Version |
Version |
Version |
|
Server |
Single |
Application |
|
Compatibility |
Single |
Module |
|
Application |
Multiple |
Application |
|
Module |
Multiple |
Module |
|
J2EE |
Multiple |
Module |
Esta tabla nos da una idea de como podemos configurar la versión 5.x para definir la visibilidad de los recursos.
Como afecta la propiedad “Application classloader policy”:
-
Con valor “Single”, hay un único ClassLoader para todas las aplicaciones empresariales.
-
Con valor “Multiple”, hay un ClassLoader diferente para cada aplicación empresarial.
Como afecta la propiedad “WAR classloader policy”:
-
Con valor “Module”, cada módulo Web (aplicación Web) dentro de la aplicación empresarial tendrá su propio ClassLoader.
-
Con valor “Application”, todos los módulos Web compartirán el mismo ClassLoader, es decir hay un único ClassLoader para toda la aplicación empresarial.
Veamos un ejemplo más complicado, pero que puede ser más esclarecedor:
Imaginemos que tenemos un módulo web (.war) que usa clases que están en un jar externo (es decir, el jar no está en su directorio lib, sino que tenemos una referencia a él definida a nivel de aplicación empresarial):
-
Si definimos el “WAR classloader policy” como “Module”, la aplicación web y el jar tendrán ClassLoader independientes. Según esto la aplicación web podrá acceder a recursos del jar puesto que tenemos una referencia a él, pero si usamos una clase del jar que intenta acceder a un recurso que está en la aplicación web, no podremos (el padre ve al hijo, pero el hijo no ve al padre).
-
Si definimos el “WAR classloader policy” como “Aplication”, hay un único ClassLoader para toda la aplicación de empresa, así que el módulo web podrá acceder a los recursos del jar y una clase del jar podrá acceder a los recursos del módulo web.
La recomendación J2EE dice que deberíamos tener la propiedad “Application classloader policy” = “Multiple” y la propiedad “WAR classloader policy” = “Module”. Es decir cada módulo es independiente de los demás.
Esto puede requerir duplicar un miso jar en los directorios WEB-INF/lib de varias aplicaciones Web. Aunque esto puede parecer un desperdicio de espacio, nos asegura que las aplicaciones son totalmente independientes, y esto, a la larga, nos facilita el mantenimiento, ya que podemos alterar una aplicación Web sin que el cambio tenga impacto sobre las demás.
