Blog de Baptiste Wicht

Un article de Baptiste Wicht    8 Commentaires

Maintenant que nous avons vu comment représenter un module au niveau Java, nous allons voir comment charger dynamiquement ces modules dans notre application.

Au niveau de Java, les classes sont chargées depuis des ClassLoader qui comme son nom l’indique est un chargeur de classes.

De base, Java utilise le ClassLoader système pour charger les classes dont notre application a besoin et ce ClassLoader contient les classes de notre application et toutes les classe qu’il a pu découvrir dans le classpath qu’on lui a fourni.

Le problème est que dans notre cas, on ne peut pas vraiment ajouter les fichiers Jar des modules au classpath étant donné que l’application ne connait pas les modules.

De plus, on ne peut théoriquement pas modifier le ClassLoader système. Je dis théoriquement, parce qu’il est possible de rajouter des fichiers ou des ressources à un ClassLoader en utilisant la réfléction et en appelant une méthode non publiques, mais je ne trouve que cette méthode soit très propre.

Nous allons donc devoir créer un nouveau ClassLoader avec lequel nous allons charger les classe de nos modules.

Il nous faudra donc procéder en deux phases :

• La première servira à explorer les fichiers des modules, à en sortir la classe du module et à récolter les URLs des fichiers Jar
• La seconde va charger les différents modules en se servant d’un ClassLoader créé avec les URLs collectées durant la première phase.

On va donc créer une classe ModuleLoader qui va nous permettre d’effectuer ces phases.

Prenons maintenant la première phase et créons une méthode qui retourne la liste des classes à charger.

Comme vous le voyez, ce n’est pas très compliqué, on parcours les fichiers Jar existant dans le dossier des modules, on ouvre le fichier Jar, on récupère le manifest et on récupère la classe du module. Ensuite de quoi, on ajoute encore l’URL du fichier Jar à la liste des URLs.

Bien entendu ce code est perfectible, il faudrait traiter le cas ou le fichier JAR n’a pas de manifest ou alors le cas ou le manifest n’a pas de classe de module et il faudrait traiter les erreurs correctement, mais ce n’est pas le but de ce billet.

On peut maintenant passer à la deuxième méthode qui va créer le ClassLoader et instancier les modules puis les retourner :

On commence donc créer un nouveau ClassLoader à partir des URLs qu’on a récupéré avec les fichiers JARs. On va utiliser un URLClassLoader qui permet de charger des classes depuis des emplacements définis par des URLs. On va lui donner comme parent le ClassLoader de la classe. Comme cela les modules qui utiliseront ce classloader pourront également utiliser les classes de l’application, ce qui est le but d’une application modulaire. Une fois qu’on a créé notre ClassLoader, on va parcourir toutes nos classes et les instancier si elles implémentent bien la bonne interface. Ensuite, on va pouvoir les ajouter à la liste et les retourner.

Encore une fois, ce code est perfectible, il faudrait traiter les erreurs et réagir aux différents cas possibles, mais j’ai essayé de faire au plus court.

Notre chargeur de modules est donc terminé.

Nous pouvons tester notre application en créant un Jar pour le module que nous avons défini dans le billet précédent et en créant un code tout simple pour les charger :

Voici ce que rendrait l’éxécution :

Plug : Simple module
Hello kernel !
Déroulement de l’application.
Bye kernel !

Comme vous le voyez, nous venons de développer une application modulaire. Bien entendu, il faut ensuite développer tous les services et les points d’extension, mais ces points sont spécifiques à l’application.

La technique présentée dans ce billet pose néanmoins un problème pour ce qui est du déploiement à la volée de module. En effet, si on charge un module après le chargement des premiers modules, on devra recréer un nouveau ClassLoader et on aura donc une partie des modules dans le premier ClassLoader et une partie des modules dans le second ClassLoader. Néanmoins, si les modules n’ont aucune intéraction entre eux, vous pouvez tout à fait envisager cette méthode pour le déploiement à la volée. Si ce n’est pas le cas, vous serez obligé de vous rabattre sur la méthode avec réfléction pour ajouter des modules dans votre ClassLoader. Je présenterai peut-être cette méthode dans un prochain billet.

Le fait d’avoir un deuxième ClassLoader pose également un problème pour les librairies qui chargent des classes à la volée comme par exemple Spring IOC ou Hibernate. Il faut voir au cas par cas pour ces librairies comment on peut leur spécifier d’utiliser notre ClassLoader. Souvent ceci est faisable en spécifiant le contextClassLoader via la méthode Thread.currentThread().setContextClassLoader(ClassLoader cl).