Cargadores de clases

Los cargadores de clases buscan y cargan archivos de clase. Los cargadores de clases permiten que las aplicaciones que están desplegadas en servidores accedan a los repositorios de clases y recursos disponibles. Los desarrolladores y los desplegadores de aplicaciones deben tener en cuenta la ubicación de los archivos de clase y recurso, y los cargadores de clases utilizados para acceder a esos archivos, para que los archivos estén disponibles para las aplicaciones desplegadas.

Consulte la siguiente información sobre los cargadores de clases en WebSphere Application Server:

Los cargadores de clases utilizados y el orden de uso

El entorno de tiempo de ejecución utiliza los siguientes cargadores de clases para buscar y cargar nuevas clases para una aplicación, en el orden siguiente:

  1. Los cargadores de rutina de carga, extensiones y CLASSPATH creados por la máquina virtual Java™.

    El cargador de clases de rutina de carga utiliza la vía de acceso de clases de arranque (normalmente las clases en jre/lib) para buscar y cargar las clases. El cargador de clases de extensiones utiliza la propiedad de sistema java.ext.dirs (normalmente jre/lib/ext) para buscar y cargar las clases. El cargador de clases de CLASSPATH utiliza la variable de entorno CLASSPATH para buscar y cargar las clases.

  2. Un cargador de clases de extensiones de WebSphere

    El cargador de clases de extensiones de WebSphere carga las clases de WebSphere Application Server que se necesitan en el tiempo de ejecución. Las clases WebSphere Application Server se proporcionan como un conjunto de paquetes OSGi. Cada paquete se carga mediante un cargador de clases diferente dentro de una red de cargadores de clases OSGi. El cargador de clases de extensiones delega a un cargador de clases de pasarela la carga de las clases desde esta red de cargadores de clases OSGi. Los paquetes exportados desde la red de cargadores de clases OSGi están visibles para las aplicaciones a través de la pasarela. Para obtener más información, consulte Modelo de cargador de clases OSGi.

    Avoid trouble Avoid trouble: Las interfaces de programación de aplicaciones (API) de Java EE (Java Platform, Enterprise Edition) se proporcionan en los paquetes javax.j2ee.*.jar, los cuales se cargan dentro de la red de cargadores de clases OSGi y están visibles para las aplicaciones a través de la pasarela. Dado que las clases desplegadas en los paquetes OSGi no están visibles para los cargadores de clases de la máquina virtual Java, no utilice la variable de entorno CLASSPATH o las propiedades del sistema java.ext.dirs y java.lang.classpath para especificar las vías de acceso a las bibliotecas que dependen de las API Java EE. Además, no utilice la variable CLASSPATH ni las propiedades java.ext.dirs y java.lang.classpath para especificar vías de acceso a las bibliotecas de aplicaciones ya que estas bibliotecas pueden generar errores de enlaces o un comportamiento imprevisto del servidor. gotcha

    El cargador de clases de extensiones WebSphere utiliza una propiedad del sistema ws.ext.dirs para determinar la vía de acceso que se utiliza para cargar clases y recursos adicionales a los que se proporcionan en los paquetes OSGi. Todos los directorios de la vía de acceso de clases ws.ext.dirs y todos los archivos JAR (Java Archive) o comprimidos de estos directorios se añaden a la vía de acceso de clases utilizada por este cargador de clases.

    El cargador de clases de extensiones de WebSphere también carga las clases del proveedor de recursos en un servidor, si el módulo de aplicación instalado en el servidor hace referencia a un recurso que está asociado con el proveedor y el proveedor especifica el nombre del directorio de los controladores de recursos.

  3. Uno o más cargadores de clases de módulos de aplicaciones que carga elementos de las aplicaciones empresariales que se ejecutan en el servidor.

    Los elementos de aplicación pueden ser módulos web, módulos EJB (enterprise bean), archivos de adaptadores de recursos (archivos RAR) y archivos JAR de dependencia. Los cargadores de clases de aplicaciones siguen las reglas de carga de clases de Java EE para cargar las clases y los archivos JAR de una aplicación de empresa. El producto permite asociar bibliotecas compartidas con una aplicación.

  4. Cero o más cargadores de clases del módulo web

    De forma predeterminada, los cargadores de clases de módulos web cargan el contenido de los directorios WEB-INF/classes y WEB-INF/libz. Los cargadores de clases de módulos Web son hijos de los cargadores de clases de aplicaciones. Puede especificar que un cargador de clases de aplicaciones cargue el contenido de un módulo web en lugar del cargador de clases de módulos web.

Jerarquía de cargador de clases

Cada cargador de clases es hijo del cargador de clases anterior. Esto es, los cargadores de clases de módulos de aplicaciones son hijos del cargador de clases de extensiones de WebSphere, que es hijo del cargador de clases Java de CLASSPATH. Siempre que tenga que cargar una clase, el cargador de clases delegará casi siempre la solicitud al cargador de clases padre. Si ninguno de los cargadores de clase padre puede encontrar la clase, el cargador de clases original intentará cargarla. Las solicitudes sólo pueden ir al cargador de clases padre, no pueden ir al cargador de clases hijo. Si el cargador de clases de extensiones de WebSphere debe encontrar una clase en un módulo Java EE, no podrá ir al cargador de clases de módulos de aplicaciones para encontrar la clase, y se producirá un error ClassNotFoundException. Una vez cargada la clase por el cargador de clases, las nuevas clases que intente cargar reutilizarán el mismo cargador de clases, o subirán en la lista de prioridad hasta que se encuentre la clase.

Políticas de aislamiento de cargadores de clases

El número y la función de los cargadores de clases de módulos de aplicaciones dependen de las políticas de cargador de clases que se especifican en la configuración del servidor. Los cargadores de clases proporcionan varias opciones para aislar aplicaciones y módulos, para que se puedan ejecutar distintos esquemas de empaquetamiento de aplicaciones en un servidor de aplicaciones.

Dos políticas de cargador de clases controlan el aislamiento de las aplicaciones y los módulos:

Tabla 1. Descripciones de políticas de cargador de clases. Las políticas disponibles incluyen Application y WAR.
Política de cargador de clases Descripción
Application Los cargadores de clases de aplicaciones cargan módulos EJB, archivos JAR de dependencia, adaptadores de recursos incorporados y bibliotecas compartidas con ámbito de aplicación. Dependiendo de la política de cargador de clases de aplicaciones, un cargador de clases de aplicaciones se puede compartir entre varias aplicaciones (Único) o ser exclusivo de cada aplicación (Múltiple). La política del cargador de clases de aplicaciones controla el aislamiento de las aplicaciones que se ejecutan en el sistema. Cuando se establece como Único, las aplicaciones no están aisladas. Cuando se establece como Múltiple, las aplicaciones están aisladas unas de otras.
WAR De forma predeterminada, los cargadores de clases de módulos web cargan el contenido de los directorios WEB-INF/classes y WEB-INF/libz. El cargador de clases de aplicaciones es el padre del cargador de clases de módulos web. Para cambiar el comportamiento predeterminado, cambie la política de cargador de clases WAR (Web Application Archive) de la aplicación.

La política de cargador de clases WAR controla el aislamiento de los módulos web. Si se establece como Aplicación, el cargador de clases de aplicaciones también cargará el contenido del módulo Web (además de los archivos EJB, los archivos RAR, los archivos JAR de dependencia y las bibliotecas compartidas). Si la política se establece como Módulo, cada módulo web recibirá su propio cargador de clases, cuyo padre será el cargador de clases de aplicaciones.

Consejo: La consola y el archivo deployment.xml subyacente utilizan distintos nombres para los valores de política de cargador de clases WAS. En la consola, los valores de política de cargador de clases WAR son Aplicación o Módulo. Sin embargo, en el archivo deployment.xml en el que se define la política, los valores de política de cargador de clases WAR son Único en vez de Aplicación o Múltiple en vez de Módulo. Aplicación es igual que Único y Módulo es igual que Múltiple.
Restricción: los cargadores de clases de WebSphere Application Server no cargan nunca módulos de cliente de aplicaciones.

Para cada servidor de aplicaciones del sistema, puede establecer la política de cargador de clases de aplicaciones como Único o Múltiple. Si establece la política de cargador de clases de aplicaciones como Único, un solo cargador de clases de aplicaciones carga todos los módulos EJB, archivos JAR de dependencia y bibliotecas compartidas del sistema. Si establece la política de cargador de clases de aplicaciones como Múltiple, cada aplicación recibe su propio cargador de clases de aplicaciones que se utiliza para cargar los módulos EJB, los archivos JAR de dependencia y las bibliotecas compartidas de esa aplicación.

El cargador de clases de aplicaciones carga clases de módulos web si la política de cargador de clases WAR de la aplicación se establece como Aplicación. Si la política de carga de clases WAR de la aplicación se establece como Módulo, cada módulo WAR recibirá su propio cargador de clases.

El siguiente ejemplo muestra que si establece la política de cargador de clases de aplicaciones como Único, un solo cargador de clases de aplicaciones carga todos los módulos EJB, archivos JAR de dependencia y bibliotecas compartidas de todas las aplicaciones en el servidor. Ese mismo cargador de clases también puede cargar módulos web si la aplicación tiene su política de cargador de clases WAR establecida como Aplicación. Las aplicaciones que tienen una política de cargador de clases WAR establecida como Múltiple utilizan otro cargador de clases para los módulos web.

Política de cargador de clases de aplicaciones del servidor: Único
Política de cargador de clases WAR de la aplicación: Múltiple

Application 1
		Module: 	EJB1.jar
		Module:	WAR1.war
	 			MANIFEST Class-Path: Dependency1.jar
				WAR Classloader Policy = Module
Application 2  
		Module:  	EJB2.jar
				MANIFEST Class-Path: Dependency2.jar
		Module:	WAR2.war
				WAR Classloader Policy = Application
Política de cargador de clases SINGLE

En el siguiente ejemplo se muestra que si se establece la política de cargador de clases de aplicaciones como Múltiple, cada aplicación en el servidor tendrá su propio cargador de clases. El cargador de clases de aplicaciones también carga sus módulos web si la política de cargador de clases WAR de la aplicación se establece como Aplicación. Si la política se establece como Módulo, cada módulo web utiliza su propio cargador de clases.

Política de cargador de clases de aplicaciones del servidor: Múltiple
Política de cargador de clases WAR de la aplicación: Múltiple

Application 1
		Module: 	EJB1.jar
		Module:	WAR1.war
				MANIFEST Class-Path: Dependency1.jar
				WAR Classloader Policy = Module
Application 2  
		Module:  	EJB2.jar
				MANIFEST Class-Path: Dependency2.jar
		Module:	WAR2.war
				WAR Classloader Policy = Application
Política de cargador de clases MULTIPLE

Modalidades de cargador de clases

La modalidad de delegación del cargador de clases, llamada también orden de cargadores de clases, determina si un cargador de clases delega la carga de clases en el cargador de clases padre. Se da soporte a los siguientes valores de modalidad de cargador de clases:

Tabla 2. Descripciones de las modalidades del cargador de clases. Las modalidades disponibles incluyen Padre primero y Padre último.
Modalidad de cargador de clases Descripción
Padre primero

También denominadas Clases cargadas con cargador de clases padre primero.

El valor Padre primero hace que el cargador de clases delegue el cargador de clases a su cargador de clase padre antes de intentar cargar la clase desde su classpath local. Este es el valor predeterminado para la política de cargador de clases y los cargadores de clases JVM estándar.
Padre último

También conocidas como Clases cargadas con cargador de clases locales primero o Aplicación primero.

El valor Padre último hace que el cargador de clases intente cargar las clases de su classpath local antes de delegar la carga de clases a su padre. Con esta política, un cargador de clases de aplicaciones puede alterar temporalmente y proporcionar su propia versión de una clase que exista en el cargador de clases padre.

Los siguientes valores determinan la modalidad de un cargador de clases:

  • Si la política de cargador de clases de aplicaciones de un servidor de aplicaciones es Único, el valor de modalidad a nivel de servidor define la modalidad de un cargador de clases de aplicaciones.
  • Si la política de cargador de clases de aplicaciones de un servidor de aplicaciones es Múltiple, el valor de modalidad a nivel de aplicación define la modalidad de un cargador de clases de aplicaciones.
  • Si la política de cargador de clases WAR de una aplicación es Módulo, el valor de modalidad a nivel de módulo define la modalidad de un cargador de clases WAR.

Modelo de cargador de clases OSGi

OSGi utiliza metadatos en el archivo de manifiesto como su modalidad de cargador de clases. En OSGi no existe ninguna vía de acceso de clases global. Cuando se instalan paquetes en la infraestructura OSGi, sus metadatos los procesa la capa del módulo y sus dependencias externas declaradas se concilian con las exportaciones con versiones declaradas por otros módulos instalados. La infraestructura OSGi averigua todas las dependencias y calcula la vía de acceso de clases necesaria independiente para cada paquete. Este método resuelve los problemas de la carga de la clase Java simple al asegurar que los siguientes requisitos se cumplen:
  • Cada paquete ofrece visibilidad sólo para los paquetes Java que exporta explícitamente.
  • Cada paquete declara explícitamente sus dependencias de paquete.
  • Los paquetes se pueden exportar en versiones específicas e importar en versiones específicas o de un rango específico de versiones.
  • Puede haber varias versiones de un paquete disponibles simultáneamente para distintos clientes.

Para obtener más información sobre OSGi, consulte el tema La infraestructura OSGi.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_classload
File name: crun_classload.html