chargement dynamique de classes

**professeur shadoko** · 28/04/2011, 10h43

bonjour
précision préliminaire: je suis croyant mais pas encore pratiquant en JMS

question:
- sur une machine un producteur envoie un message contenant un objet
- du coté de la machine récepteur on reçoit ce message mais on n'a pas la classe correspondante (eh oui ça arrive!)

existe-t-il un mécanisme (plus ou moins standard ... ou déjà écrit par un autre) qui permette le chargement dynamique de la classe correspondante et la reconstitution "propre" de cet objet?

On a déjà ça avec des mécanismes sur RMI (je penses à JINI) mais peut-on se passer d'écrire un ClassLoader qui fasse une demande à un serveur de classe (sur http par exemple)?

merci pour tout tuyau ou suggestion

**Jimmy_** · 28/04/2011, 11h32

Bonjour,

Croyant et pratiquant JMS, le messaging d'objet utilise le mécanisme de serialization des objets.
Tu vas recevoir un java.io.Serializable, après tu en fais ce que tu veux.

Le travail de JMS est terminé.

**professeur shadoko** · 28/04/2011, 11h45

Envoyé par Jimmy_

Bonjour,

Croyant et pratiquant JMS, le messaging d'objet utilise le mécanisme de serialization des objets.
Tu vas recevoir un java.io.Serializable, après tu en fais ce que tu veux.

Le travail de JMS est terminé.

moui.... mais si tu n'as pas la classe sous la main l'objet ne sera pas dé-serialisé!

Il me semble (mais peut-être me trompes-je) que ça doit être assez courant d'avoir un producteur et un consommateur sur deux machines différentes avec la possibilité que le récepteur n'aie pas la bonne classe pour dé-serialiser....
C'est un phénomène hyper-courant dans des architectures réparties (c'est pour ça que je citais "feu" JINI)

edit: je peux écrire ma propre usine à gaz en faisant circuler des MarshalledObjects et en ayant mon propre ClassLoader coté récepteur ... mais pourquoi réécrire quelque chose qui a sans doute été déjà fait

**Jimmy_** · 28/04/2011, 12h10

Ceci dit, nous on s'envoie des Bytes on ne fait transiter que la 'charge utile'.

Tu ne sais pas du tout l'objet que tu vas recevoir, même pas une liste d'objet possible ?

**professeur shadoko** · 28/04/2011, 13h43

Envoyé par Jimmy_

Tu ne sais pas du tout l'objet que tu vas recevoir, même pas une liste d'objet possible ?

aucune chance... on est en informatique répartie: les machines sur le réseau peuvent inclure des codes nouveaux à tout moment et donc il faut que les machines réceptrices soient capables de récupérer dynamiquement ces codes.

(pour moi ce n'est pas une situation exceptionnelle...)

**Logan Mauzaize** · 28/04/2011, 14h05

JMS n'étant qu'une spécification, ils ne doivent pas avoir prévu ça dans l'API, si t'as besoin d'envoyer des informations dont la forme et la nature peut changer à tout moment pourquoi passer par la sérialisation Java.

Je pense que le mieux c'est de sérialiser via un processus plus standard que celui proposé par Java.

Il y a aucun miracle qui fera passer le code (comportement) de tes classes et celui de leurs dépendances.

Je te conseille éventuellement de consulter la documentation de ton implémentation pour savoir comment la paramétrer et si par exemple tu peux spécifier le ClassLoader.

**Jimmy_** · 28/04/2011, 14h39

J'ai connu il fut un temps un middleware qui utilisait massivement l'introspection via l'API de reflection Java.

Je ne sais pas si ton besoin est couvert par cette API. Surtout si tu n'as pas à priori l'objet sous le coude ou dans un jar.

**professeur shadoko** · 28/04/2011, 16h49

Envoyé par Nemek

Je pense que le mieux c'est de sérialiser via un processus plus standard que celui proposé par Java.

Il y a aucun miracle qui fera passer le code (comportement) de tes classes et celui de leurs dépendances.

Sans faire de miracles ça se fait couramment dans d'autres contextes
d'informatique répartie et Java est très bien fait pour ça.

le seul truc est de savoir si quelqu'un l'a déjà fait dans un contexte JMS.

Je te conseille éventuellement de consulter la documentation de ton implémentation pour savoir comment la paramétrer et si par exemple tu peux spécifier le ClassLoader.

là tu as raison .... mais tu me demandes de lire une documentation!

(de plus l'implantation des agents qui écrivent et lisent dans JMS doit être abstraite par rapport au produit support JMS -il y a une raison pour ça-)

**tchize_** · 28/04/2011, 17h09

Toute solution impliquant le transport des classes serait propriétaire, et donc adieu l'abstraction.

Transférer les classes ne résoud rien. Comment les utiliser puisqu'on ne les a jamais vues avant? RMI a un tout autre fonctionnement, il arrive qu'on code par exemple une fenetre coté serveur et qu'on l'envoie pour affichage au client par RMI. Je vois mal l'intéret de ce genre de chose en java. Un message se sont des données auquel le consommateur s'attends. Il faudrait plutot que vous revoyez votre formattage des messages. JMS est un bus à message, RMI est une interface permettant d'invoquer des méthodes à distance, la logique n'est donc pas la meme

En "gros" MapMessage a été créé dans l'idée de plutot y tapper des List, des Map ou des choses dans ce gout la, pas des classes custom. Pour les structure complexes, préférer l'envoi d'un chaine JSON et son traitement coté client

**professeur shadoko** · 28/04/2011, 17h25

Envoyé par tchize_

Toute solution impliquant le transport des classes serait propriétaire, et donc adieu l'abstraction.

soit....

Transférer les classes ne résoud rien. Comment les utiliser puisqu'on ne les a jamais vues avant?

là je sais: le code recepteur fait de l'introspection puis utilise ces informations en fonction de tas de critères sur la nature de ses découvertes.

la bonne idée serait sans doute de faire ces opérations avant d'envoyer le message mais il faut que je vérifie si les exigences de découplage permettent ça effectivement de façon réaliste (je veux dire c'est le code récepteur qui a sa logique de collecte/structuration/utilisation des informations et le code émetteur n'en a -presque- aucune idée)

**tchize_** · 28/04/2011, 17h31

mais pourquoi dans ce cas aller f*** ces données dans une classe qu'on sérialize après plutot que les mettre dans un truc genre JSON ou xml?

**professeur shadoko** · 28/04/2011, 17h39

Envoyé par tchize_

mais pourquoi dans ce cas aller f*** ces données dans une classe qu'on sérialize après plutot que les mettre dans un truc genre JSON ou xml?

parce que ce sont de vraies classes pas simplement des structures de données.
encore une fois utiliser des classes qu'on n'a jamais vu ni d'ève ni d'adam ça se fait pour des tas de raisons: ici le transfert des objets est asynchrone et obéit à une logique "message" au lieu d'être directement livré (comme en RMI ou JINI).

**Logan Mauzaize** · 29/04/2011, 08h33

RMI a besoin que le Stub soit déployé sur le client RMI, non ?

Si je cromprends bien tu veux également faire transiter les classes de tes objets ? Dans ce cas JMS n'est vraiment pas le bon choix.

Car ce genre de système suppose une négociation entre les deux parties afin d'échanger au préalable les classes (comment gérer les différentes version d'une même classe ?).

Ensuite l'envoie de données si tout est ok.

Il ne faut pas oublier que dans JMS le broker doit être capable de stocker pour transmettre le message même si l'émetteur est déconnecté.

**tchize_** · 29/04/2011, 09h10

Pour le problème de déploiement des classes, j'aborderais éventuellement le problème de cette façon:

un repository central avec les classes de transfert en version X

quand l'émetteur upgrade ses classes, il poste un message sur une queue précise (ou un topic persistant si de nombreux clients) disant à quelle version il passe. Le clients, en recevant ce message, se déconnectent, téléchargent la mise à jour et redémarrent.

**professeur shadoko** · 29/04/2011, 09h40

Envoyé par Nemek

RMI a besoin que le Stub soit déployé sur le client RMI, non ?

non.

je reprends mon raisonnement à la base: dans un service comme "feu" JINI on recevait des objets dont on n'avait pas nécessairement la classe. Si la classe était inconnue le ClassLoader demandait la classe à l'émetteur et zou on pouvait se servir de cet objet (il s'agit bien d'objets avec un comportement pas de simples données emballées dans un objet).

Naïvement je vois JMS comme un moyen de diffuser des objets sur la base du paradigme publish/subscribe. Le mot "message" est relativement trompeur à ce niveau: il ne s'agit pas forcément de données portant diagnostic d'un évènement mais bien de véritables objets. Dans ce cas il me semble évident que le récepteur n'a pas forcément la classe de l'objet reçu et qu'un mécanisme de chargement de classe doit rentrer en action. Je suis surpris que ça ne soit pas dans la spec et je serais encore plus surpris qu'une implantation (ou des librairies ad-hoc) ne traitent pas le problème.
Avant de réaliser ça "à la main" je préfère profiter de librairies déjà écrites.

**professeur shadoko** · 29/04/2011, 09h45

Envoyé par Nemek

Il ne faut pas oublier que dans JMS le broker doit être capable de stocker pour transmettre le message même si l'émetteur est déconnecté.

tu veux dire que le broker doit aussi avoir la classe?
il ne devrait pourtant pas avoir a deserialiser le flot d'octet .... je n'y connais rien mais ça me semble peu probable.

**professeur shadoko** · 29/04/2011, 09h49

Envoyé par tchize_

Pour le problème de déploiement des classes, j'aborderais éventuellement le problème de cette façon:

un repository central avec les classes de transfert en version X

quand l'émetteur upgrade ses classes, il poste un message sur une queue précise (ou un topic persistant si de nombreux clients) disant à quelle version il passe. Le clients, en recevant ce message, se déconnectent, téléchargent la mise à jour et redémarrent.

moui.... je vais réfléchir à cet aspect. (dans le cas d'espèce il y a peu de clients et beaucoup d'émetteurs).
mais pourquoi se déconnecter et redémarrer?

**Logan Mauzaize** · 29/04/2011, 10h26