Contrôle d'existence d'un fichier

Je dois contrôler la présence d'un fichier (pdf) généré par une autre application sur un serveur HTTP via son url. S'il existe je l'ouvre dans une nouvelle fenêtre d'IE.
Le problème est que la génération de ce fichier peut être longue, ce qui fait que quand je teste que le fichier existe, je peux avoir une réponse ok bien que le fichier ne soit pas "complet". Du coup quand je l'ouvre j'ai une page blanche (si je fais un reload le fichier s'affiche).

Comment puis je contrôler que le fichier a bien fini d'être généré ?

As tu essayé de regarder la taille de ton fichier ?
Si le fichier en cours d'écriture à un taille de 0 ou trés trés petite tu peux considérer qu'il n'est pas complétement achevé. (Mais à verfier quand meme.....)
Une solution assez laide consiste à créer un fichier temporaire quand ton fichier pdf est crée et ton prog java teste lui si ce fichier temporaire existe ou non et là tu es sur que ton pdf soit crée (ou non).

J'avais bien pensé à la solution du fichier temporaire càd l'autre génère le fichier avec un nom bidon puis le renomme mais ça leur plait pas.

Le coup de la taille du fichier me parait pas sûr car le pdf peut avoir n'importe quelle taille or si je teste une taille de fichier mais qu'en fait le fichier doit faire plus, ça plante toujours.

Moi je pensais plus à un truc du genre j'essaie d'ouvrir le fichier en exclusif et si j'ai pas le droit c'est qu'il est encore en cours d'écriture et donc qu'il n'est pas fini d'être généré mais je sais pas si ça peut marcher et surtout je sais pas comment le coder.

Tant qu'un fichier est en cours d'écriture, tu ne peux pas y accéder en lecture.

Tu fais donc un truc comme ça pour tester :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

File inputFile = ton PDF   try { BufferedInputStream bis = new BufferedInputStream(new FileInputStream(inputFile)); bis.read(); System.out.println("Fichier OK"); } catch (IOException e) { System.out.println("Fichier non accessible"); } finally { bis.close(); }

---

Deux questions par rapport à ta solution :
j'accède à mon pdf par une url et pas par un chemin physique alors est-ce "File" marche quand même ?
La génération du fichier n'est pas fait par un processus java alors est-ce que je vais bien voir que le fichier est en cours d'écriture ?

Citation:

---

Envoyé par mouste79

j'accède à mon pdf par une url et pas par un chemin physique alors est-ce "File" marche quand même ?

---

Normalement oui.

Citation:

---

Envoyé par mouste79

La génération du fichier n'est pas fait par un processus java alors est-ce que je vais bien voir que le fichier est en cours d'écriture ?

---

Disons que ma solution ne te dit pas qu'il est en cours d'écriture mais qu'il n'est pas lisible. Peut importe que ça soit ton java ou pas qui bloque le fichier.

Essaie et tu verras bien. Moi je fais ça en local, ça marche bien.

Pour lire le fichier tu ulises URL.openStream() qui retourne un InputStream.
Par contre pour ta deuxième question je ne sais pas meme si j'ai la trés forte conviction que tu ne pourras pas lire si le fichier est en cours d'écriture ce qui est un tant soit peu logique ! même si ce n'est pas un processus java qui fait l'écriture

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

URL url; InputStream ins = null; HttpURLConnection urlConnection; BufferedInputStream bis; try { url = new URL(urlPDF); urlConnection = (HttpURLConnection) url.openConnection(); ins = url.openStream(); bis = new BufferedInputStream(ins); bis.read(); pdfOk = "OK"; } catch (IOException ex) { pdfOk = "KO"; } finally { bis.close(); }

---

Voici le code que je teste mais j'ai un soucis avec le bis.close() dans le finally : il demande de gérer une ioexception. Je vais pas rajouter un try catch dans le finally ???

Citation:

---

Envoyé par mouste79

Je vais pas rajouter un try catch dans le finally ???

---

Si bien sûr ! ;)

Et qu'est ce que je dois fermer d'autre ?
URL ?
InputStream ?
HttpURLConnection ?

Et du coup qu'est ce que je fais dans le catch du finally vu que j'ai pas pu fermer mon BufferedInputStream ?

Et ben tu fais ce que tu veux. J'peux pas t'apprendre java quand même. C'est toi qui voit comment tu veux gérer tes exceptions.

URL pas besoin de fermer.
InputStream faut fermer.

Code:

---

1 2 3 4 5

try { bis.close(); } catch (IOException e) { e.printStackTrace(); }

---

ou peu importe... c'est pas bien important de toute façon comme exception là. C'est rarissime.

Citation:

---

Et qu'est ce que je dois fermer d'autre ?
URL ?
InputStream ?
HttpURLConnection ?

---

Tu fermes tout ce dont tu n'as plus besoin, donc ici si j'ai bien compris tout

Après test en réel, ça ne fonctionne pas, la méthode read() ne lève pas d'exception même si le fichier est encore en cours de génération.
Quelqu'un aurait-il une autre piste ?

Salut,

Citation:

---

Envoyé par mouste79

J'avais bien pensé à la solution du fichier temporaire càd l'autre génère le fichier avec un nom bidon puis le renomme mais ça leur plait pas.

---

C'est pourtant la meilleure solution à mon avis... Qu'est-ce qui les dérange la-dedans ?

a++

Mon chef m'a dit c'est à toi de le gérer et quand chef dit...

Apparemment il avait réussi à le faire en VB, ils essayaient d'ouvrir le fichier en lecture exclusive et ça marchait.

Sinon y'aurait pas moyen de tester un caractère de fin de fichier ?

Citation:

---

Après test en réel, ça ne fonctionne pas, la méthode read() ne lève pas d'exception même si le fichier est encore en cours de génération.
Quelqu'un aurait-il une autre piste ?

---

c'est quand même étonnant.

deux solutions :
1 - le programme qui écrit dans le fichier doit impérativament locké le fichier en cours d'écriture de sorte que tu puisses recevoir l'exception désirée.

2 - tu testes à t0 la taille du fichier, si a t0 + 1 seconde le fichier a toujours la même taille c'est que normalement il est écrit en intégralité. Cependant cette méthode manque un peu de rigueur.

bye

Citation:

---

Envoyé par mouste79

Mon chef m'a dit c'est à toi de le gérer et quand chef dit...

Apparemment il avait réussi à le faire en VB, ils essayaient d'ouvrir le fichier en lecture exclusive et ça marchait.

Sinon y'aurait pas moyen de tester un caractère de fin de fichier ?

---

En Java (RandomAccessFile) comme en VB, tu peux ouvrir ton fichier en lecture exclusif mais dans ton cas, lecture via le protocole HHTP même VB aurait des problèmes.

Car tu nes gères pas (heureusement) comment le serveur HTTP lit les fichiers à envoyer. Explique ça à ton chef si il est assez ouvert et à l'écoute, il va le comprendre et l'accepter.

Si il ne veut pas passer par un fichier temporaire, à la réception il faut que tu testes que le fichier reçu correspond bien au format PDF (spécification PDF).

Bon courage

Je confirme tes soupçons sur la lecture via HTTP, après avoir eu des explications, la solution utilisée en VB était faite avec une lecture du fichier en local.
Alors comme le pdf est un serveur IIS, voilà l'usine à gaz à mettre en place...
Sinon pour le controle du bon format pdf, ok mais je sens que dans peu de temps il vont me passer des fichiers word...

En tout cas, merci d'avoir éclairer mes lanternes, j'aurais appris pleins de choses avoir ce problème.

ce probleme ressemble fort aux problemes d'exclusion mutuelle, alors pourquoi ne pas gerer ca un peu comme pour l'exclusion mutuelle, avec une sorte de semaphore. Je m'explique. Avant de generer ton fichier .pdf, tu creer un petit fichier d'un octet qui a comme simple but de specifier que ton fichier et en cours de generation. Ensuite tu suprimes ce fichier. Comme ca, ton client aura juste a verifier l'existance de ce fichier avant d'acceder au fichier ( pas de probleme de savoir si le fichier est termine de genere ou pas, si il existe, stop ! ) et attendre qu'il n'existe plus...