Discussion :

[Alain Defrance]

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 :

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

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 :

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

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 .

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 ).

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

merci d'avance.

[adiGuba]

Salut,


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


a++

[Alain Defrance]

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

[adiGuba]

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 :

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
	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++

[Alain Defrance]

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 :

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

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 ?

[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

[millie]

Code :

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

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.