Instanciation transparente avec la réflexion utilisant ClassLoader

Version imprimable

Bonjour,

Dans le cadre d'un projet d'étude j'ai a développer deux applications qui doivent communiquer entre elles grâce a des instances sérialisées.
Pour bien faire j'ai séparé tous les beans traversant le réseau dans une librairie. Le problème est que si l'une des deux applications n'utilise des version légèrement différentes de la lib, la désérialisation provoquera une exception puisque la définition des classes sera différente. Pour résoudre ce problème j'ai choisi de mettre cette lib accessible via une URL sur le web, et charger dynamiquement au démarage le .jar
J'ai donc le code suivant (utilisant pour les test un fichier local) :
Code:

1 2 3 4 5 6 7 File f = new File("C:/libmt.jar"); URL[] urls = {f.toURL()}; ClassLoader loader = new URLClassLoader(urls); Class c = Class.forName("beans.Token", true, loader); Object o = c.newInstance(); Method m = c.getMethod("getVersion"); System.out.println(m.invoke(o));
Mon problème est que les instances de ces classes sont présente très régulièrement dans l'application, et que passer systématiquement pas des fonction callback deviendra rapidement lourd.

Ce qui résolverais mon preblème serait de ceci :
Code:

1 2 3 4 5 6 File f = new File("C:/libmt.jar"); URL[] urls = {f.toURL()}; ClassLoader loader = new URLClassLoader(urls); Class c = Class.forName("beans.Token", true, loader); Token t = (Token) c.newInstance(); // Sauf que le type Token n'éxiste pas ... t.getVersion();
J'ai pensé a passer par une Factory qui me retournera une instance, mais ca restera toujours une instance d'Object, et je devrais toujours passer par des callbacks.

J'ai pensé aussi à passer par une interface implémenté par tous les beans du .jar, je pourais alors caster mon Object, sauf que ca ne m'apportera pas plus de méthodes accessibles :evilred:.

Pour finir j'ai remarqué l'existence de l'interface Future, je ne sais pas si ca répondrais a mon problème et je ne suis pas arrivé a la mettre en place ...

Je suis donc plus ou moins entrain de me dire que la solution sera de récup le .jar et relancer l'application (à la windows :vomi:).

PS : ne serait-il pas possible de préciser a System d'utiliser une classeloader de plus ?

merci d'avance.

18/01/2009, 13h35
adiGuba

Salut,

Comment tu lances ton application ?
Via une ligne de commande ? Via un jar autoexecutable ? Via Java Web Start ?

a++
18/01/2009, 13h36
Alain Defrance

Je lance actuellement mon application via ligne de commande, mais a terme je compte la déployer sous forme de jar autoexecutable

Avec JWS cela aurait été tout simple...

Dans tous les cas pour compiler tu auras besoin d'avoir la librairie dans ton classpath, pour que le compilateur puisse vérifier les appels de méthode et la cohérence du code.

Pour l'exécution le problème vient du fait que tes classes locales et distantes doivent être accessible via le même classloader. Il faudrait passer par une classe qui servirait uniquement à lancer ton code avec le bon classloader.

Par exemple qqchose comme cela :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 public static void main(final String[] args) throws Exception { // Nom de la classe principale String mainClassName = "monpackage.Main"; // Classloader contenant la classe distante et ton code ClassLoader loader = URLClassLoader.newInstance( new URL[] { // Le fichier distant : new URL("http://site.com/tonarchives.jar"), // Le fichier local : new File("./programme.jar").toURI().toURL() }); // On charge La classe principale : final Class<?> mainClass = Class.forName(mainClassName, true, loader); // Et on appelle la méthode main() : mainClass.getMethod("main", String[].class).invoke(null, (Object)args); }
Ca devrait marcher...

Sinon pourquoi ne pas opter pour une sauvegarde un peu plus souple (comme les XMLEncoder/XMLDecoder...)

a++

Merci beaucoup pour l'intéret porté.

Je n'avais vraiment pas du tout pensé a utiliser le classloader avant de lancer le vrai programme et ca me paraissait parfait. J'ai donc éssayer de faire marcher celà mais sans succes. En effet les deux jar sont préalablement compilés, et on ne peut donc pas instancier un type d'un jar dans l'autre, or c'est précisément ce dont j'ai besoin. Ce code est donc correcte mais il ne peut résoudr emon problème.

Hisotire de développer un peu plus l'interet, le but est de faire transiter des instances directement dans des OutputStream et InputStream provenant d'un socket (entre client et serveur). Le problème est que si on met a jour les beans, la serialisation soulevera des exceptions, alors je voudrais rendre cette synchronisation transparante.

Je suis arrivé a une solution mais je ne pense pas que ca soit terrible.
En fait j'ai un .jar partagé via internet, et un autre .jar dans lequelle il y a uniquement des interface implémenté par les classes de lu jar partagé. Du coup j'ai plus qu'a lier le jar contenant les interfaces aux projets (client et serveur), stocker et caster vers l'interface, je peut donc a nouveau appeler mes méthodes :
Code:

1 2 3 4 5 6 File f = new File("C:/libmt.jar"); URL[] urls = {f.toURL()}; ClassLoader loader = new URLClassLoader(urls); Class c = Class.forName("beans.Token", true, loader); TokenInterface ti = (TokenInterface) c.newInstance(); //: instance de Token stocké dans un type TokenInterface. t.getVersion();
On garde donc la possibilité de modifier le code pour peu que l'on ne touche pas a l'interface.

T'en pense quoi ? Ai-je mal appliqué ton code ?

19/01/2009, 13h02
bulbo

Jette un oeil à la classe java.lang.reflect.Proxy, il te suffira de créer une interface de chaque coté correspondant aux objets sérialisés et ensuite c'est l'implémentation de ton proxy qui fera le reste.

Dans ton code tu utiliseras (via le proxy) tes classes sérialisées exactement comme une classe normale.

Autre avantage du proxy, tu peux soulever une exception lors de l'appel d'une méthode qui n'existe pas sur l'objet sérialisé.. pas d'exception a la desérialisation, juste à l'utilisation erronée.

Ca c'est pour faire ce que tu veux, par contre au niveau design cela aurait peut-être été un peu plus élégant de mettre dans un jar a part les objets que tu partages et d'avoir client et serveur qui dépendent de ce jar, du coup tu peux caster dans la bonne classe direct sans te prendre la tête. Moi je ferais comme ça, ne serait-ce que pour des raisons de qualité logicielle (vérifications faites par le compilo, maintenance du client et du serveur..)

Bulbo ;)

Citation:
Envoyé par kazou
Code:

1 2 3 4 5 6 File f = new File("C:/libmt.jar"); URL[] urls = {f.toURL()}; ClassLoader loader = new URLClassLoader(urls); Class c = Class.forName("beans.Token", true, loader); TokenInterface ti = (TokenInterface) c.newInstance(); //: instance de Token stocké dans un type TokenInterface. t.getVersion();
On garde donc la possibilité de modifier le code pour peu que l'on ne touche pas a l'interface.

T'en pense quoi ? Ai-je mal appliqué ton code ?
Ca marche ça ?
libmt.jar, c'est bien une bibliothèque non liée à ton application ?

Je dis ça parce que pour charger dynamiquement des classes d'autres jar, j'avais un ClassLoader 100 fois plus compliqués avec des ZipInputStream etc.

19/01/2009, 13h30
bulbo

Oui ça marche ;)

Les classloaders savent se débrouiller avec des jars donc inutile de passer par des ZipInputStream et autre..

Bulbo ;)
19/01/2009, 13h37
millie

Citation:

Envoyé par bulbo

Oui ça marche ;)

Les classloaders savent se débrouiller avec des jars donc inutile de passer par des ZipInputStream et autre..

Bulbo ;)

T'es en train de me dire que ça, ça sert à rien : http://subversion.developpez.com/pro...assLoader.java :aie:
19/01/2009, 14h11
Alain Defrance

Citation:

Envoyé par millie

T'es en train de me dire que ça, ça sert à rien : http://subversion.developpez.com/pro...assLoader.java :aie:

En fait les Jar sont de simples zip comme t'a pu le voir puisque tu peut le parcourir de la même facon au travers de ZipFile (a noter qu'il existe aussi JarFile qui permet en plus de récupérer un Manifest) et permet de récupérer toutes les Entry.

Mais ClassLoader sais aussi le faire tout seul :aie:.

@bulbo : Ok je vais voir du coté des Proxy, en effet ça a l'air d'être totalement ce que j'ai créer comme comportement ...
Au niveau du design, j'ai en fait deux lib, une regroupand les instances transitant serializables au travers du réseau, et une autre qui est linké statiquement aux deux applications et regroupe les interfaces et la classe permettant d'instancer les type présente dans cette load dynamiquement.

Je vous tien au courant ;)
19/01/2009, 14h34
bulbo

Attention ce que toi tu as fait n'est pas tout à fait identique.

Pour que cela fonctionne (sans ClassCastException ou autre) il faut que l'objet sérialisé implémente vraiment ton interface TokenInterface et si jamais l'interface change tu te prends direct un ClassCastException.

Avec le proxy c'est inutile, l'interface peut être définie seulement du côté client par exemple et peu importe l'objet sérialisé, tant que les méthodes que tu appelleras sur ton proxy existent cela fonctionnera, même si une ou plusieurs méthodes sont manquantes (mais pas utilisées) sur l'objet.

Bulbo ;)

PS pour millie> j'en ai bien peur en effet :aie:

Alors j'ai tenté de mettre en place la Class proxy mais sans succès, du moins je me prend une belle exception.

Dans mon main j'ai :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
    public static void main(String[] args) throws MalformedURLException, ClassNotFoundException, InstantiationException, IllegalAccessException, NoSuchMethodException, IllegalArgumentException, InvocationTargetException, Exception {
        File f = new File("C:/libmt.jar");
        URL[] urls = {f.toURI().toURL()};
        ClassLoader loader = new URLClassLoader(urls);
 
        Class tokenClass = Class.forName("dao.Token", true, loader);
 
        Class [] interfaces = {ProtoToken.class};
        ProtoToken pt = (ProtoToken) Proxy.newProxyInstance(tokenClass.getClassLoader(), interfaces, new ProxyHandler(tokenClass));
 
        System.out.println(pt.getVersion());
    }

ProxyHandler :

Code:

1
2
3
4
5
6
7
8
9
10
public class ProxyHandler implements InvocationHandler {
        private Class type;
 
        public ProxyHandler (Class type) {
            this.type = type;
        }
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            return type.newInstance();
        }
}

ProtoToken :

Code:

1
2
3
public interface ProtoToken {
    public Float getVersion();
}

Token (dans le jar) :

Code:

1
2
3
4
5
6
7
8
9
10
11
public class Token implements /*ProtoToken,*/ Serializable {
    private Float version;
 
    public Token() {
        this.version = 0.2F;
    }
 
    public Float getVersion() {
        return version;
    }
}

Et l'exception :

Code:

1
2
3
4
Exception in thread "main" java.lang.ClassCastException: dao.Token cannot be cast to java.lang.Float
        at $Proxy0.getVersion(Unknown Source)
        at testloader.Main.main(Main.java:49)
Java Result: 1

Quelqu'un aurait-il une idée d'où ça peut venir ?

19/01/2009, 18h11
bulbo

Je te colle un exemple qui marche dans la soirée.. il te suffira d'adapter ;)
19/01/2009, 19h37
Alain Defrance

Merci beaucoup, d'ici la je tente d'avancer :aie:
19/01/2009, 20h54
bulbo

4 pièce(s) jointe(s)

Alors voici un exemple réduit à sa plus simple expression, mais de manière générale l'InvocationHandler est fini à 99%

Token: la classe que l'on serialise
TokenInterface: l'interface locale que l'on va utiliser pour accéder à l'objet
TokenInvocationHandler: la classe qui fait le boulot qu'il faut pour le proxy
Main: une classe de test qui montre un exemple d'utilisation du proxy

Amuses-toi bien,

Bulbo ;)
19/01/2009, 21h46
Alain Defrance

Voilà, j'ai adapté, c'est vraiment génial, tout marche pour le mieux.

Un grand merci à tous le monde :lahola:, sans vous j'étais fichu :aie: