Les ClassLoaders dans JBossDans le cas de Jboss, les différents ClassLoader dédiés aux applications packagées (les war, jar et autres ear) permettent la communication et la comparaison de deux instances d’une classe, même si ces instances ont été chargées par deux ClassLoader différents. De même, la mise à jour d’une classe et son rechargement sera sensible dans toutes les applications. Ceci est possible en utilisant une version légèrement différente du système de délégation. Plutôt que de passer directement la demande de chargement de classe au ClassLoader qui les a chargé, les différents ClassLoader de Jboss demandent d’abord ce chargement à un ClassLoader commun, l’UnifiedClassLoader. Celui-ci charge d’abord la classe, en utilisant à son tour le système de délégation. Le UnifiedClassLoader conserve également la liste des classes déjà chargées, de manière à optimiser les traitements. Tout cela est optimisé pour permettre d’unifier les objets chargés depuis différents types d’applications, différents emplacements et en utilisant différents protocoles. Mais ça ne résout pas pour autant le problème du rechargement des classes. En fait, dans ce cas, c’est très simple. Il suffit pour l’un des ClassLoader d’applications (prenons par exemple le cas du WarClassLoader) de demander à changer de UnifiedClassLoader. Comme il n’est lié que de manière dynamique à ce ClassLoader, c’est très facile. Une fois qu’il a changé d’instance d’UnifiedClassLoader, celui-ci va pouvoir charger la nouvelle version de la classe, dont bénéficieront également les autres ClassLoader d’applications, puisque le fait que cette classe ait changé suffit à rendre son ancien UnifiedClassLoader obsolète. Ce mécanisme très puissant permet donc un rechargement à la volée très facile des objets, associé au maintien d’un ensemble de classes homogène quelque soit le ClassLoader qui a permis de les charger. Dans le cadre des EJBs déployés sur un serveur Jboss, il est important de noter que l’unité élémentaire rechargée lorsqu’un changement de classes est repéré est la web-application. En effet, tout autre comportement induirait des incohérences entre versions de classe, conduisant au type de problèmes évoqués plus haut. En conséquence, la présence de cet outil permet, lors du fonctionnement d’un serveur d’application, de redéployer les applications sans arrêter le serveur, en ayant toutefois la contrainte de devoir redémarrer l’application, puisqu’elle est considérée dans ce cas comme atomique. Auteur : Nicolas Delsaux
|
||