Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

1.2.2. Les modules et le système de chargement de la nouvelle classe modulaire de JBoss EAP 6.

1.2.2.1. Modules

Un module est un regroupement logique des classes utilisées pour le chargement de classes et pour la gestion de dépendances. JBoss EAP 6 identifie deux types de modules, parfois appelés modules statiques et dynamiques. Cependant, la seule différence entre les deux est la façon dont ils sont emballés.
Modules statiques
Les modules statiques sont prédéfinis dans le répertoire EAP_HOME/modules/ du serveur d'applications. Chaque sous-répertoire représente un module et contient un sous-fichier de configuration main/ qui contient un fichier de configuration (module.xml) et tous les fichiers JAR requis. Le nom du module est défini dans le fichier module.xml. Toutes les API fournies par le serveur de l'application sont des modules statiques, y compris les API Java EE, et les autres API comme JBoss Logging.

Exemple 1.1. Exemple de fichier module.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.1.15.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Le nom du module, com.mysql, doit correspondre à la structure du répertoire du module, à l'excepté du nom de sous-répertoire main/.
Les modules fournis dans les distributions JBoss EAP se trouvent dans un répertoire system se trouvant lui-même dans le répertoire JBOSS_HOME/modules. Cela les rend séparés de tout module fourni par une tierce partie.
Tout produit mis en couche de Red Hat, se superposant sur JBoss EAP 6.1 ou version supérieure installera également leurs modules dans le répertoire system.
La création de modules statiques personnalisés peut être utile si plusieurs applications sont déployées sur un même serveur utilisant les mêmes bibliothèques de tierce partie. Au lieu d'un regroupement de ces bibliothèques pour chaque application, un module contenant ces bibliothèques peut être créé et installé par l'administrateur JBoss. Les applications peuvent ensuite déclarer une dépendance explicite sur les modules statiques personnalisés.
Les utilisateurs doivent s'assurer que les modules personnalisés soient installés dans le répertoire JBOSS_HOME/modules, en utilisant un répertoire par couche de modules. Cela garantit que les versions personnalisées de modules qui existent déjà dans le répertoire system soient bien chargées à la place des versions fournies. Ainsi, les modules utilisateur auront la priorité sur les modules fournis par le système.
Si vous utilisez la variable d'environnement JBOSS_MODULE_PATH pour changer les emplacements où JBoss EAP cherche les modules, le produit ira chercher dans une structure de sous-répertoire system dans un des emplacements spécifiés. Une structure de sous-répertoire system doit exister quelquepart dans les emplacements spécifiés dans JBOSS_MODULEPATH.
Modules dynamiques
Les modules dynamiques sont créés et chargés par le serveur d'applications pour chaque déploiement JAR ou WAR (ou sous-déploiement d'un EAR). Le nom d'un module dynamique est dérivé du nom de l'archive déployée. Comme les déploiements sont chargés sous forme de modules, ils peuvent configurer des dépendances et peuvent être utilisés comme dépendances par d'autres déploiements.
Les modules ne sont chargés qu'en fonction des besoins. Cela a généralement lieu quand une application est déployée avec des dépendances implicites ou explicites.
Rapporter un bogue