Discussion :

[amelA]

Bonjour,
J'ai un problème avec la lecture d'un fichier, voici mon problème:
j'ai une application client/serveur (avec RMI).
une des classes de l'application cliente contient les instructions de lecture d'un fichier suivantes:

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
 
 String monFichier = "C:\\session.txt";
        String fichierContenu= "";
        int num_session = 0;
      try
      {
        RandomAccessFile raf = new RandomAccessFile(monFichier, "r");
        String ligne;
        while ( (ligne = raf.readLine()) != null )
        {
          fichierContenu += ligne;
        }
        System.out.println("contenu du fichier: "+fichierContenu);
        num_session = Integer.parseInt(fichierContenu.trim());
      }
    catch (IOException e){ System.out.println("erreur dans: " + e);}
        //appel d'une méthode du serveur
        Collection equip = port.getEquip(num_session);

lorsque je lance le serveur ensuite le client sur la machine "serveur", la lecture du fichier se fait normalement, mais quand je lance le serveur sur la machine "serveur" et le client sur une autre machine "cliente" il me sort une erreur : "C:/session.txt" (le fichier spécifié est introuvable) or que le fichier existe dans le c:/ de la machine "cliente".
je n'y comprend rien
Quel est le problème dans ce cas?
merci.

[Invité]

salut,
tu utilise rmi donc le client cherchera le fichier "C:/session.txt" chez le serveur car tout simplement le code des fonctions sera éxécutés au serveur ce qui explique le problème. c'est un des principaux notions des systèmes distribués.

[amelA]

salut,
non, pas du tout, la portion du code se trouve dans une classe qui se trouve rien qu'au niveau du client et donc elle est executée au niveau du client (grace à la machine virtuelle de JAVA) et non pas du serveur. les méthodes du serveur sont executées à son niveau que lorsqu'elles sont appelées, or ce n'est pas le cas ici.
Cela est confirmé par :
1- quand un fichier texte existe au niveau du C:/ du serveur, ça fonctionne pas, ce qui explique que le code est executé coté client.
2- je vient de faire un test sur un autre pc et par miracle ça marche.
donc ça doit être une question de configuration de PC, reste à savoir ce que ça peut être.
Si quelqu'un a une réponse, ça serait sympa de nous éclairer.
merci encore.

[iohack]

Puisque ton code est local au client, je ne vois pas de problème.
QQ pistes :
- respectes-tu bien la casse dans le nom du fichier
- n'as-tu pas oublié - sur la machine qui ne marche pas - de doubler le backslash (ou bien mis un double slash à la place) --> pour éviter ce problème, ne pas taper le séparateur en dur dans les chaines, utiliser File.separatorChar.
- Si ce fichier est créé par ton application java, as-tu bien géré la fermeture du fichier (méthode close() dans un bloc finally) ?
etc.

[amelA]

Bonjour,
merci pour ces indications,
1 - le nom du fichier est "session .txt" donc pas de problème de casse.
2 - voici ma déclaration:

Code :

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

 String monFichier = "C:\\session.txt";

, ici le slash est doublé.
3 - le fichier existe déja au préalable, il n'est pas créé par l'application.
jusque là je crois que j'ai respecté tes indications!
seulement j'ai pas bien saisi cela:

pour éviter ce problème, ne pas taper le séparateur en dur dans les chaines, utiliser File.separatorChar.

merci et bonne journée à tous.

[adiGuba]

Salut,


Et si tu essayes de créer le fichier depuis Java ? Juste pour voir...

Sinon File.separatorChar permet de faire des programmes portable en évitant de mettre des chemins spécifiques à un système d'exploitation...

a++

[iohack]

Pour compléter par un exemple :
File.separatorChar vaudra "\" sur des systèmes d'exploitation de type windows et "/" sur des systèmes d'exploitation de type unix.
Comme l'a dit AdiGuba, cela évite de devoir modifier tous tes fichiers sources et de recompiler le jour où tu migres l'application vers une machine possédant un autre système d'exploitation.
Et sans avoir à migrer de machine, cela permet de distribuer l'application sans se soucier l'OS cible --> portabilité, l'intérêt majeur de java.

[amelA]

merci pour ces explications!