Chargeurs de classe
Les chargeurs de classe recherchent et chargent des fichiers de classe. Ils activent les applications qui sont déployées sur des serveurs pour accéder aux référentiels de classes et de ressources disponibles. Les développeurs d'applications et les déployeurs doivent tenir compte de l'emplacement des fichiers classe et de ressources, ainsi que des chargeurs de classe utilisés pour accéder à ces fichiers, afin de les mettre à la disposition des applications déployées.
Vous trouverez des informations relatives aux chargeurs de classe dans WebSphere Application Server:
- Chargeurs de classe utilisés et ordre d'utilisation
- Règles d'isolement du chargeur de classe
- Modes du chargeur de classe
- modèle de chargeur de classe OSGi
Chargeurs de classe utilisés et ordre d'utilisation
L'environnement d'exécution du produit utilise les chargeurs de classe ci-dessous pour rechercher et charger les nouvelles classes pour une application dans l'ordre suivant :
- les chargeurs de classe d'amorçage, d'extensions et CLASSPATH créés par la machine virtuelle Java™,
Le chargeur de classe d'amorçage utilise le chemin d'accès aux classes d'amorçage (en général, il s'agit de classes se trouvant dans jre/lib) pour rechercher et charger des classes. Le chargeur de classe des extensions utilise la propriété système java.ext.dirs (en général, jre/lib/ext) pour rechercher et charger des classes. Le chargeur de classe de CLASSPATH utilise la variable d'environnement CLASSPATH pour rechercher et charger des classes.
- un chargeur de classe d'extensions WebSphere,
Le chargeur de classe d'extensions WebSphere charge les classes WebSphere Application Server requises au moment de l'exécution. Les classes WebSphere Application Server sont fournies sous forme d'ensemble de bundles OSGi. Chaque bundle est chargé par un chargeur de classe distinct d'un réseau de chargeurs de classe OSGi. Le chargeur de classe des extensions délègue le chargement des classes depuis ce réseau de chargeurs de classe OSGi à un chargeur de classe de passerelle. Les packages exportés depuis le réseau de chargeurs de classe OSGi sont visibles pour les applications via la passerelle. Pour plus d'informations, voir modèle de chargeur de classe OSGi.
Eviter les incidents: Les interfaces de programme d'application (API) J2EE (Java Platform, Enterprise Edition) sont fournies dans les bundles javax.j2ee.*.jar, qui sont chargés dans le réseau de chargeurs de classe OSGi et rendus visibles pour les applications via la passerelle. Etant donné que les classes déployées dans les bundles OSGi ne sont pas visibles pour les chargeurs de classe de la machine virtuelle Java, n'utilisez pas la variable d'environnement CLASSPATH ni les propriétés système java.ext.dirs et java.lang.classpath pour spécifier les chemins d'accès aux bibliothèques qui dépendent des API Java EE. De plus, n'utilisez pas CLASSPATH, java.ext.dirs ou java.lang.classpath pour spécifier les chemins d'accès aux bibliothèques d'applications car ces bibliothèques peuvent générer des erreurs de liaison ou des comportements de serveur inattendus.gotcha
Le chargeur de classe des extensions WebSphere utilise la propriété système ws.ext.dirs afin de déterminer le chemin d'accès qui est utilisé pour charger les classes et les ressources supplémentaires qui ne sont pas fournies dans des bundles OSGi. Chaque répertoire du chemin d'accès aux classes ws.ext.dirs et chaque fichier archive Java (JAR) ou compressé figurant dans ces répertoires sont ajoutés au chemin d'accès aux classes utilisé par ce chargeur de classe.
Le chargeur de classe d'extensions WebSphere charge également les classes du fournisseur de ressources sur un serveur si un module d'application installé sur le serveur désigne une ressource associée au fournisseur et que ce dernier indique le nom des répertoires des pilotes de ressources.
- Un ou plusieurs chargeurs de classe de module d'application qui
chargent les éléments d'applications d'entreprise s'exécutant sur
le serveur.
Les éléments d'application peuvent être des modules Web, des modules EJB, des archives d'adaptateur de ressources (fichiers RAR), et les fichiers JAR de dépendances. Les chargeurs de classe des applications respectent les règles de chargement des classes Java EE pour charger les classes et les fichiers JAR à partir d'une application d'entreprise. Le produit vous permet d'associer des bibliothèques partagées à une application.
- Aucun ou plusieurs chargeurs de classe de module Web
Par défaut, les chargeurs de classe de module Web chargent le contenu des répertoires WEB-INF/classes et WEB-INF/lib. Les chargeurs de classe de module Web sont des enfants des chargeurs de classe de l'application. Vous pouvez spécifier le chargement du contenu d'un module Web par le chargeur de classe d'une application plutôt que le chargeur de classe du module Web.

Chaque chargeur de classe est enfant du chargeur de classe précédent. En d'autres termes, les chargeurs de classe du module d'application sont des enfants du chargeur de classe des extensions WebSphere, lui-même enfant du chargeur de classe Java de CLASSPATH. Chaque fois qu'une classe doit être chargée, le chargeur de classe délègue la demande à son chargeur de classe parent. Si aucun des chargeurs de classe parent ne peut trouver la classe, le chargeur de classe d'origine tente de la charger. Les demandes ne peuvent être adressées qu'à un chargeur de classe parent ; elles ne peuvent pas être envoyées à un chargeur de classe enfant. Si le chargeur de classes d'extensions WebSphere est requis pour la recherche d'une classe dans un module Java EE, la demande ne peut pas être adressée à un chargeur de classe de module d'application, et une erreur ClassNotFoundException est générée. Dès qu'une classe est chargée par un chargeur de classe, toute nouvelle classe qu'il tente de charger utilise le même chargeur de classe ou parcourt la liste de priorités jusqu'à ce que la classe soit trouvée.
Règles d'isolement du chargeur de classe
Le nombre et la fonction des chargeurs de classe de module d'application dépendent des règles de chargeur de classe indiquées dans la configuration du serveur. Les chargeurs de classe fournissent plusieurs options d'isolement des applications et des modules permettant d'exécuter différents schémas de mise en forme des applications sur un serveur d'applications.
Deux règles de chargement de classe contrôlent l'isolement des applications et des modules :
Stratégie de chargeur de classe | Description |
---|---|
Application | Les chargeurs de classe d'application chargent des modules EJB, des fichiers JAR de dépendances, des adaptateurs de ressources intégrés et des bibliothèques partagées au niveau de l'application. Selon la règle du chargeur de classe de l'application, un chargeur peut être partagé par plusieurs applications (Un seul) ou un chargeur différent est affecté à chaque application (Plusieurs). La règle du chargeur de classe d'application contrôle l'isolement des applications qui s'exécutent sur le système. Lorsque celle-ci a la valeur Un seul, les applications ne sont pas isolées. Si elle a la valeur Plusieurs en revanche, les applications sont isolées les unes des autres. |
WAR | Par défaut, les chargeurs de classe de module Web chargent le contenu des
répertoires WEB-INF/classes et WEB-INF/lib. Le chargeur de classe d'application est le parent du chargeur de classe de module Web. Il est possible de modifier
le comportement par défaut en changeant la règle du chargeur de classe WAR de l'application.
La règle du chargeur de classe WAR contrôle l'isolement des modules Web. Si cette règle correspond à Application, le contenu du module Web est également chargé par le chargeur de classe de l'application (outre les fichiers EJB, RAR, JAR de dépendances et les bibliothèques partagées). Si la règle choisie est Module, chaque module Web reçoit son propre chargeur de classe dont le parent est celui de l'application. Conseil : La console et le fichier deployment.xml sous-jacent utilisent des noms différents comme valeurs de stratégie de chargeur de classe WAR. Dans la console, les valeurs de stratégie de chargeur de classe WAR
sont Application ou Module. Toutefois, dans le fichier deployment.xml sous-jacent dans lequel est définie la stratégie, les valeurs de stratégie de chargeur de classe WAR sont Unique au lieu de Application,
ou Plusieurs au lieu de Module. Application correspond à Unique, et Module à Plusieurs.
|
Vous pouvez utiliser les valeurs Un seul et Plusieurs pour définir une règle de chargeur de classe d'application pour chaque serveur d'applications système. Quand la règle du chargeur de classe d'application a la valeur Un seul, un seul chargeur de classe d'application charge tous les modules EJB, les fichiers JAR de dépendances et les bibliothèques partagées sur le système. Lorsque la règle du chargeur de classe correspond à Plusieurs, chaque application reçoit son propre chargeur de classe destiné à charger les modules EJB, les fichiers JAR de dépendances et les bibliothèques partagées de l'application.
Un chargeur de classe d'application charge des classes à partir des modules Web si la règle du chargeur de classe WAR de l'application est associée à la valeur Application. En revanche, si elle correspond à Module, chaque module WAR reçoit son propre chargeur de classe.
L'exemple suivant montre qu'avec une règle du chargeur de classe d'application correspondant à Un seul, un chargeur charge la totalité des modules EJB, les fichiers JAR de dépendances et les bibliothèques partagées de toutes les applications sur le serveur. Ce chargeur de classe d'application unique peut également charger les modules Web si la règle du chargeur de classe WAR d'une application a la valeur Application. Les applications pour lesquelles la règle du chargeur de classe WAR a la valeur Module utilisent un chargeur de classe distinct pour les modules Web.
Règle du chargeur de classe d'application du serveur : Unique
Règle du chargeur de classe WAR de l'application : Module
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

L'exemple ci-après montre qu'avec une règle du chargeur de classe d'application correspondant à Plusieurs sur un serveur d'applications, chaque application sur celui-ci possède son propre chargeur de classe. Un chargeur de classe d'application charge également les modules Web si la règle du chargeur de classe WAR de l'application a la valeur Application. Si la règle correspond à Module, un module Web utilise son propre chargeur de classe.
Règle du chargeur de classe du serveur : Plusieurs
Règle du chargeur de classe WAR de l'application : Module
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

Modes du chargeur de classe
Le mode de délégation du chargeur de classe, également connu sous le nom ordre du chargeur de classe, détermine si un chargeur de classe délègue le chargement des classes au chargeur de classe père. Les valeurs de mode de chargeur de classe suivantes sont prises en charge :
Mode de chargeur de classe | Description |
---|---|
Parent en premier Egalement qualifié de Classes chargées en premier avec un chargeur de classes parent. |
Lorsque vous utilisez le mode Parent en premier, le chargeur de classe tente de déléguer le chargement des classes à son chargeur de classe parent avant de tenter de charger la classe à partir de son chemin d'accès aux classes local. Il s'agit de la règle de chargeur de classe par défaut, ainsi que de la règle des chargeurs de classe JVM standard. |
Parent en dernier Egalement qualifié de Classes chargées en premier avec un chargeur de classe local ou Application en premier. |
Lorsque vous utilisez le mode Parent en dernier le chargeur de classe tente de charger les classes à partir de son chemin d'accès aux classes local avant de déléguer le chargement des classes à son parent. Grâce à cette règle, un chargeur de classe d'application peut remplacer une classe d'application existante dans le chargeur de classe parent et fournir sa propre version de la classe. |
Les paramètres ci-dessous permettent de déterminer le mode d'un chargeur de classe :
- Si la règle du chargeur de classe d'application d'un serveur d'applications est associée à la valeur Unique, la valeur du mode au niveau du serveur définit le mode du chargeur de classe au niveau d'une application.
- Si la règle du chargeur de classe d'application d'un serveur d'applications est associé à la valeur Plusieurs, la valeur du mode au niveau de l'application définit le mode du chargeur de classe d'une application.
- Si la règle du chargeur de classe WAR d'une application est associée à la valeur Module, la valeur du mode au niveau du module définit le mode d'un chargeur de classe WAR.
modèle de chargeur de classe OSGi
- Chaque bundle offre une visibilité des packages Java qu'il exporte explicitement.
- Chaque bundle déclare ses dépendances de package explicitement.
- Les packages peuvent être exportés à des versions spécifiques et importés à des versions spécifiques ou à partir d'une plage spécifique de versions.
- Plusieurs versions d'un package peuvent être disponibles en même temps que différents clients.
Pour plus d'informations sur OSGi, voir la rubrique Structure OSGi Framework.