Discussion :

[frog]

Salut,

Afin de faire un system de plugin pour mon appli et en utilisant un URLClassLoader pour chaque plugin. Pour cela j'override le system property java.system.class.loader et en utilisant mon propre SystemClassLoader avec en autre la autre la fct loadClass():

classLoaders est une liste de PluginClassLoader.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
public class MySystemClassLoader extends ClassLoader{
 private List classLoaders;
 
    public MySystemClassLoader parent) throws MalformedURLException, IOException{
        super(parent);
        classLoaders = initClassLoaders();
    }
    public Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
        PluginClassLoader cl=null;   // extends URLClassLoader
        try {
                return super.loadClass(name, resolve);
            } catch (ClassNotFoundException ex) {}
 
        for (Iterator i = classLoaders.iterator(); i.hasNext(); ) {
            cl = (PluginClassLoader)i.next();
            try {
                return cl.loadClass(name);
            } catch (ClassNotFoundException ex) {}
        }
        throw new ClassNotFoundException(name);
    }
}

Ca marche bien mais je me demande juste si il n'y a pas une facon plus efficace. Et surtout ca ne correspond pas au model de delegation de Java2. Au lieu de deleguer en remontant je delegue en redescendant.
La hierarchie des mes ClassLoader est la suivante.

BootstrapClassLoader
.............|
ExtensionClassLoader
.............|
SystemClassLoader
|............|..............|
Plugin1 Plugin2 Pluginx

Je suppose que tomcat utilise ce genre de principe donc si qq un sait comme ca marche chez les pros ou alors a une bonne idee je serai bien content.
Merci

[Jacques - 06]

Ouah quand on commence à écrire ses propres classloader et surtout à remplacer ceux du système par les siens, il faut vraiment être sûr de son coup

En effet il y a plus simple mais tu es sur la bonne voie

Le principe est de ne pas toucher à la hiérarchie de ClassLoader du système (surtout si tu fais cela dans un conteneur J2EE cela peut donner des résultats surprenants). Par contre l'idée est de charger tes plugins avec l'URLClassLoader (comme tu l'avais deviné).

Le principe est le suivant:
1 - ton plugin doit impérativement implémenter une interface
2 - l'interface du plugin doit être déployée dans le classpath de l'application
3 - l'implémentation de ton plugin doit être dans un jar indépendant du classpath de l'application, mais dans un répertoire connu de celle-ci
(jusque là rien que du très logique)
4 - il est préférable que la classe principale de ton plugin soit un JavaBean, ou au moins une classe avec un constructeur sans paramètres (c'est plus simple)
5 - pour accéder à ton plugin:
5.1 - instancier un URLClassLoader en lui passant en paramètre l'url du ou des jars d'implémentation de ton plugin, ainsi que le classloader de l'application (sauf si ton plugin n'utilise aucune classe du classpath de ton application, ou au contraire utilise certaines de ses classes mais dans des versions différentes)
5.2 - instancier ta classe avec l'URLClassloader
5.3 - caster l'instance avec l'interface du plugin
5.4 - utiliser le plugin

Attention, le chargement de l'URLClassLoader et l'instanciation du plugin par celui-ci sont couteux en terme de performances, donc utiliser une factory qui fasse un cache.

Jacques Desmazières

[frog]

C'est vrai que c'est plus simple et ca marche aussi bien. Mais qu'est ce que tu entends par factory?

Merci Jacques

[Jacques - 06]

Mais qu'est ce que tu entends par factory?

A ces fameux Design Patterns ce n'est pas que pour la théorie, on s'en sert dans la vraie vie

En fait c'est une classe à qui tu délègue l'instanciation d'une classe ou d'une hiérarchie de classes afin d'assurer certains services (gestion de cache, initialisation, gestion du nombre d'instances, ...).
Dans notre cas, la factory instancie un seul URLClassLoader (à l'initialisation ou lors du premier appel) et instancie la classe (pas encore l'instance). La classe est alors conservée et utilisée pour instancier celle-ci (le plugin) à chaque demande, à moins bien sûr que tu ne veuille qu'une seule instance de ton plugin, ou que celui-ci soit thread-safe, dans ce cas c'est la factory qui fait office de singleton (encore un Design Pattern ! )

J'espère que cela répond à ta question

Jacques Desmazières