Que veut dire cette exception :
 
Erreur identification java.rmi.UnmarshalException : error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: serveur.Commandes_Stub(no security manager:RMI class loader disabled)
 
Il trouve pas mon fichier Commandes_Stub sur le client ?
ou cela n'a rien avoir ?

 
Non, comme tu as désactivé la sécurité, il a désactivé RMI.
Il veut pas de RMI tant que y'a pas de politique de sécurité mise en place. Tu remets ta politique de sécurité comme il faut et ça devrait aller.

Et comment on fait ?
 
Car j'ai rien désactivé niveau RMI ...

... sous Dos

 
t'as pas activié explicitement le security manager de RMI et il te faut une classe coté client que tu n'as pas -> class loading on the fly mais c'est permis uniquement si tu le spécifies explicitement.
 
Par exemple suppose que tu as une méthode sur ton serveur du genre
 

 
typiquement si la classe Customer n'est pas disponible chez le client il va la loader à la volée depuis le réseau. Je parie que ton jar client ne contient pas toutes les classes

Bonjour Darklord
 
Et bien ce n'est pas le principe même du RMI ?
 
En fait voilà mon appli marche nickel sans passer l'objet Commandes en RMI
 
Quand j'ai voulu mettre l'objet Commandes chez le serveur, voici mes étapes :  
J'ai une classe Commandes que je veux que le client accède a cet objet via RMI.
Chez le client g fait une interface ICommandes de Commandes
Et j'ai la classe Commandes.
 
J'ai compilé ICommandes et Commandes.
J'ai donc obtenu ICommandes.class et Commandes.class
Ensuite J'ai fait un
rmic -d . serveur.Commandes
Cela m'a généré un Commandes_Stub.class et un Commandes_Skel.class
 
Ensuite coté client, J'ai mis le ICommandes.class et le Commandes_Stub.class
Et à partir de là, dans les classes (toujours du côté client) utilisant l'objet Commandes j'ai remplacé tout les "Commandes" par des "ICommandes".
 
Derniere precision, le client accède à l'objet Commandes en Remote.
 
Vous m'avez bien suivi    ?
 
Donc ma question est : Ai-je bien suivi "le protocole RMI"?
Donc pour en revenir avec Darklord, la classe Commandes est bien dispo avec le ICommandes.class et le Commandes_Stub.class.
Sinon, ça se pourrai que je suis à côté de la plaque, car ça marche pas
 
Sinon, j'ai activé le firewall de mon XP, ça n'a rien à voir ? car mon PC fait le serveur et le client en même temps.
 
J'espere avoir donné le plus de précision.

 
non le class loading on the fly est une feature qui n'était pas disponible initalement.
 
Pour tes autres problèmes, je ne vois rien pour l'instant mais c'est intéressant. Si tu trouves ca serait cool de poster la solution.
 
Le stub tu l'as bien mis dans le package serveur? Sinon pour ton histoire d'interface là ca ressemble plus a du bidouillage non?

 
Il faut que le client ne connaisse le serveur qu'a travers une interface qui etend java.rmi.Remote, ce qui a l'air d'etre le cas chez toi. Donc ca me semble bien.  
 

 
Faudrait avoir un bout de ton code pour dire ce qui va pas. Tu fais une erreur en pensant que la classe Commandes_Stub doit se trouver seulement du cote du client. Elle doit se trouver du cote de tout ceux qui manipulent un objet qui a l'interface de ton objet distant.  
 
Par exemple, si ton serveur decide de se parler a lui-meme non pas en utilisant un "this" mais une reference ICommande (modulo la facon dont il a eu cette ref mais on va pas chippoter ), il faut qu'il ait la classe Commandes_Stub.
 
De meme, si un objet A appelle une methode foo(ICommande toto) sur un objet B, alors il faut que dans le classpath de la JVM de B se trouve Commandes_Stub.
 
Quand tu commences a developper en RMI, mets les classes chez tout le monde pour pas multiplier les problemes inutilement. Une fois que ca marche, tu pourras commencer a bien separer les classes et envisager du chargement dynamique de code.
 
Looz.