communication servlet applet

Marsh Posté le 21-10-2004 à 14:31:22

Bonjour,
J'ai un problème de communication entre une applet et un servlet.
Mon applet discute de manière standard avec ma servlet pour reccupérer un executable qui sera ensuite utiliser par l'application.

Code :

/**/
public static String CONTENT_TYPE = "Content-type";
public static String URL_ENCODED = "application/x-www-form-urlencoded";
/**
* récupère le launcher côté server et le recopie chez le client
*
*/
public void getAndSaveLauncher() {
//throws IOException, MalformedURLException {
try {
log("On est rentré dans getAndSaveLauncher" );
byte[] launcherAsByteArray;
BufferedInputStream bufferedIn;
// on prepare la connection
URL appletUrl = this.getCodeBase();
URL url =
new URL(
appletUrl.getProtocol(),
appletUrl.getHost(),
appletUrl.getPort(),
FILE_SENDER_URL + URL_LAUNCHER);
// on se connecte
URLConnection uc = url.openConnection();
uc.setDoOutput(true);
uc.setDoInput(true);
uc.setUseCaches(false);
uc.setRequestProperty(CONTENT_TYPE, URL_ENCODED);
log("La taille contentLength : " + uc.getContentLength());
// on recupere le contenu de notre exe
launcherAsByteArray = new byte[uc.getContentLength()];
bufferedIn = new BufferedInputStream(uc.getInputStream(), 1024);
bufferedIn.read(launcherAsByteArray);
bufferedIn.close();
// on l'ecrit sur le poste client
putLocalFile(
uc.getInputStream(),
FILE_LAUNCHER,
directoryPath);
log("fin de getAndSaveLauncher" );
} catch (Exception e) {
e.printStackTrace();
}
}

Se code fonctionne très bien en environement de dev (tomcat sur le poste de dev). Lors des tests d'intégration (sun one webserver 6.1), cette méthode échoue dans environ 20% des cas : la connexion avec la servlet échoue (l'adresse est pourtant correcte, tous les streams entre l'applet et la servlet sont clos).
J'ai commencé par utilisé un objet serializé pour encapsuler un stream qui serait lié directement à l'executable, mais j'ai obtenu le même résultat.
J'ai cherché sur le forum et sur google: ce problème est déjà arrivé à différentes personnes, mais je n'ai pas trouvé de solutions.
Quelqu'un aurait il rencontré un problème similaire et, surtout, trouvé une solution? :jap:

Reply

Marsh Posté le 21-10-2004 à 14:31:22

Reply

Marsh Posté le 21-10-2004 à 14:35:48

je ne sais oas pour ton problême
mais, qu'est ce qui t'empeche de relancer le download quand tu vois que ca plante ?
c'est un peu bourrin de mettre tout le fichier en mémoire (ton tableau de byte), tu peux pas plutot copier directement sur le disque ?

Reply

Marsh Posté le 21-10-2004 à 15:10:55

Le timeout necessaire pour indiquer que le download à planté est trop long. L'application se fige tant qu'on ne l'obient pas. Je pourrais relancer le download, s'il echoue, mais du moment ou la connection echoue une fois, elle echouera pour toute la durée de la session.
Pour le timeout, j'ai trouvé des solutions à base de thread qui limite ce timeout. Je suis tout à fait d'accord pour la copie sur le disque, je mettrais cela en place dès que le bug de connection sera résolu.

Reply

Marsh Posté le 30-11-2004 à 10:41:47

Lorsque j'ai posté mon message, je n'ai pas indiqué que la jvm utilisée est celle de MS (j'y peux rien, c'est le client qui impose ça). En passant par le jdk 1.4.x, le problème ne se pose plus.

Reply

Marsh Posté le 30-11-2004 à 14:44:03

Question bête et pas tout à fait dans le sujet, mais normalement une applet ne peut pas écrire sur le disque local du client... ton putLocalFile, il fait comment?
(bon, je ne suis pas un spécialiste des droits des applets, je crois savoir qu'y a un système de signature d'applet qui fait qu'alors elles ont plus de droits)

Reply

Marsh Posté le 30-11-2004 à 15:11:14

l'applet est en effet signée. Pour la version jvm MS, on utilisait les classes com.ms.security.

Reply

communication servlet applet

Sujets relatifs:

Leave a Replay