Dialoge Process

[Erik Mazoyer]

Bonjour à tous,

Dans nos développements nous avons besoin de transformer un Flash en image sous Java.
Pour cela nous avons écrit une passerelle JNI pour shooter l'animation en C++ et la récupérer en Java.
Malheureusement l'ActiveX Flash n'est pas stable dans le temps et quand il plante, il plante aussi la JVM.

Pour éviter cela, nous envisageons d'écrire un application C++ et de la lancer depuis Java.
De ce fait, si l'application plante, la JVM n'est pas perturbée.

Mais (car il y a toujours un mais) il faut mettre en place une communication entre l'application et la JVM (lancer l'application pour chaque rendu est trop consommateur de temps).
Les solutions de dialogue basées sur ip sont proscrites car l'application doit pouvoir fonctionner sur tout ordinateur avec ou sans Firewall sans que l'utilisateur n'est à modifier sa configuration (souvent il n'en a pas le droit).

J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process lancé par Java.

Pour tester cela j'ai écrit une appli C++ qui fait un écho, elle lit en permanence sur std::cin et écrit ce qu'elle lit sur std::cout.
Je l'ai testée sur l'invite de commande avec succès.

Du coté Java :

Process process = new ProcessBuilder(processFile.getCanonicalPath()).start();
OutputStream outputStream = process.getOutputStream();
InputStream inputStream = process.getInputStream();

Ensuite je délègue à des threads le remplissage de l'outputStream et la lecture de l'inputStream.
Seulement voila, je reçois bien le message de l'appli comme quoi elle s'est lancée mais j'ai beau envoyer des caractères sur l'outputStream, je ne reçois rien sur l'inputstream.

J'ai essayé la lib Shell d'adiGuba (com.developpez.adiguba.shell) sans que ça ne change quoi que ce soit.

Ave- vous déjà réalisé cela ?
Avez-vous des pistes de réflexions.

Merci d'avoir lu jusqu'ici :)

Erik

[jerome moliere]

Salut erik,
moi à ta place (mais je n'y suis pas) je ferai du CORBA sur un bus même
local et cela serait plus clean architecturalement et t'aurais pas de
galÚres du type de celle rencontrée

My 2 cents
jerome
PS:
en plus t'as tout ce qu'il faut cÎté Java dans une JVM récente

Bonjour à tous,
Dans nos développements nous avons besoin de transformer un Flash en image
sous Java.
Pour cela nous avons écrit une passerelle JNI pour shooter l'animation en
C++ et la récupérer en Java.
Malheureusement l'ActiveX Flash n'est pas stable dans le temps et quand il
plante, il plante aussi la JVM.
Pour éviter cela, nous envisageons d'écrire un application C++ et de la
lancer depuis Java.
De ce fait, si l'application plante, la JVM n'est pas perturbée.
Mais (car il y a toujours un mais) il faut mettre en place une
communication entre l'application et la JVM (lancer l'application pour
chaque rendu est trop consommateur de temps).
Les solutions de dialogue basées sur ip sont proscrites car l'application
doit pouvoir fonctionner sur tout ordinateur avec ou sans Firewall sans que
l'utilisateur n'est à modifier sa configuration (souvent il n'en a pas le
droit).
J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process
lancé par Java.
Pour tester cela j'ai écrit une appli C++ qui fait un écho, elle lit en
permanence sur std::cin et écrit ce qu'elle lit sur std::cout.
Je l'ai testée sur l'invite de commande avec succÚs.
Process process = new
ProcessBuilder(processFile.getCanonicalPath()).start();
OutputStream outputStream = process.getOutputStream();
InputStream inputStream = process.getInputStream();
Ensuite je délÚgue à des threads le remplissage de l'outputStream et la
lecture de l'inputStream.
Seulement voila, je reçois bien le message de l'appli comme quoi elle s'est
lancée mais j'ai beau envoyer des caractÚres sur l'outputStream, je ne
reçois rien sur l'inputstream.
J'ai essayé la lib Shell d'adiGuba (com.developpez.adiguba.shell) sans que
ça ne change quoi que ce soit.
Ave- vous déjà réalisé cela ?
Avez-vous des pistes de réflexions.
Merci d'avoir lu jusqu'ici :)
Erik

[Erik Mazoyer]

Salut Jérome,

Et tu aurais une architecture de test à proposer coté Java et C++ ?
Je ne suis pas contre cette solution, mais j’ai peur qu’elle soit chronophage :).

Erik

De : jerome moliere [mailto:***@gmail.com]
Envoyé : mardi 22 février 2011 16:54
À : Erik Mazoyer
Cc : java
Objet : Re: Dialoge Process

Salut erik,
moi à ta place (mais je n'y suis pas) je ferai du CORBA sur un bus même local et cela serait plus clean architecturalement et t'aurais pas de galÚres du type de celle rencontrée

My 2 cents
jerome
PS:
en plus t'as tout ce qu'il faut cÎté Java dans une JVM récente
Le 22 février 2011 16:45, Erik Mazoyer <***@uni-learning.com<mailto:***@uni-learning.com>> a écrit :
Bonjour à tous,

Dans nos développements nous avons besoin de transformer un Flash en image sous Java.
Pour cela nous avons écrit une passerelle JNI pour shooter l'animation en C++ et la récupérer en Java.
Malheureusement l'ActiveX Flash n'est pas stable dans le temps et quand il plante, il plante aussi la JVM.

Pour éviter cela, nous envisageons d'écrire un application C++ et de la lancer depuis Java.
De ce fait, si l'application plante, la JVM n'est pas perturbée.

Mais (car il y a toujours un mais) il faut mettre en place une communication entre l'application et la JVM (lancer l'application pour chaque rendu est trop consommateur de temps).
Les solutions de dialogue basées sur ip sont proscrites car l'application doit pouvoir fonctionner sur tout ordinateur avec ou sans Firewall sans que l'utilisateur n'est à modifier sa configuration (souvent il n'en a pas le droit).

J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process lancé par Java.

Pour tester cela j'ai écrit une appli C++ qui fait un écho, elle lit en permanence sur std::cin et écrit ce qu'elle lit sur std::cout.
Je l'ai testée sur l'invite de commande avec succÚs.

Du coté Java :

Process process = new ProcessBuilder(processFile.getCanonicalPath()).start();
OutputStream outputStream = process.getOutputStream();
InputStream inputStream = process.getInputStream();

Ensuite je délÚgue à des threads le remplissage de l'outputStream et la lecture de l'inputStream.
Seulement voila, je reçois bien le message de l'appli comme quoi elle s'est lancée mais j'ai beau envoyer des caractÚres sur l'outputStream, je ne reçois rien sur l'inputstream.

J'ai essayé la lib Shell d'adiGuba (com.developpez.adiguba.shell) sans que ça ne change quoi que ce soit.

Ave- vous déjà réalisé cela ?
Avez-vous des pistes de réflexions.

Merci d'avoir lu jusqu'ici :)

Erik

[Jean-Baptiste Defard]

[j***@gmail.com]

Tres bonne remarque je ne sais pas si un tel runtime est ou pas plus lourd qu'une registry corba..a voir..en tt cas plus simple a administrer
Jerome
---- Envoyé avec BlackBerry® d'Orange ----

-----Original Message-----
From: Jean-Baptiste Defard <***@defard.com>
Date: Tue, 22 Feb 2011 17:46:01
To: java<***@u-strasbg.fr>
Subject: Re: Dialoge Process

Salut,
Ou alors en plus moderne : AMQP pour la communication. Coté Java, je sais qu'il y a un composant Camel. il existe une (au moins) implémentation AMQP en C++.
seulement 1 cent (car je n'ai pas encore eu l'occasion de tester la chose).
--
Jean-Baptiste

Le 22/02/2011 16:53, jerome moliere a écrit : Salut erik,
moi à ta place (mais je n'y suis pas) je ferai du CORBA sur un bus même local et cela serait plus clean architecturalement et t'aurais pas de galÚres du type de celle rencontrée

My 2 cents
jerome
PS:
en plus t'as tout ce qu'il faut cÎté Java dans une JVM récente

Le 22 février 2011 16:45, Erik Mazoyer <***@uni-learning.com <mailto:***@uni-learning.com> > a écrit :



Bonjour à tous,
 
Dans nos développements nous avons besoin de transformer un Flash en image sous Java.
Pour cela nous avons écrit une passerelle JNI pour shooter l'animation en C++ et la récupérer en Java.
Malheureusement l'ActiveX Flash n'est pas stable dans le temps et quand il plante, il plante aussi la JVM.
 
Pour éviter cela, nous envisageons d'écrire un application C++ et de la lancer depuis Java.
De ce fait, si l'application plante, la JVM n'est pas perturbée.
 
Mais (car il y a toujours un mais) il faut mettre en place une communication entre l'application et la JVM (lancer l'application pour chaque rendu est trop consommateur de temps).
Les solutions de dialogue basées sur ip sont proscrites car l'application doit pouvoir fonctionner sur tout ordinateur avec ou sans Firewall sans que l'utilisateur n'est à modifier sa configuration (souvent il n'en a pas le droit).
 
J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process lancé par Java.
 
Pour tester cela j'ai écrit une appli C++ qui fait un écho, elle lit en permanence sur std::cin et écrit ce qu'elle lit sur std::cout.
Je l'ai testée sur l'invite de commande avec succÚs.
 
Du coté Java :
 
Process process = new ProcessBuilder(processFile.getCanonicalPath()).start();
OutputStream outputStream = process.getOutputStream();
InputStream inputStream = process.getInputStream();
 
Ensuite je délÚgue à des threads le remplissage de l'outputStream et la lecture de l'inputStream.
Seulement voila, je reçois bien le message de l'appli comme quoi elle s'est lancée mais j'ai beau envoyer des caractÚres sur l'outputStream, je ne reçois rien sur l'inputstream.
 
J'ai essayé la lib Shell d'adiGuba (com.developpez.adiguba.shell) sans que ça ne change quoi que ce soit.
 
Ave- vous déjà réalisé cela ?
Avez-vous des pistes de réflexions.
 
Merci d'avoir lu jusqu'ici :)
 
Erik


--
<http://www.eclipsecon.org/2011/static/image/friends/100x100_speaking.gif> J.MOLIERE - Mentor/J
auteur Eyrolles

[Erik Mazoyer]

Salut Jean-Baptiste,

Tu vas bien ?


Ø Ou alors en plus moderne : AMQP pour la communication.

Je ne connaissais pas, ça à l’ai pas mal du tout.
Mais je ne dois pas utiliser la couche ip et :
AMQP Advanced Message Queuing Protocol<http://www.amqp.org/> is an open standard designed to support reliable, high-performance messaging over the Internet.
https://cwiki.apache.org/qpid/amqp-advanced-message-queueing-protocol.html

Toi un spécialiste de Windows, tu n’as jamais lancé une appli depuis Java et dialogué avec elle par les streams ?

Erik

De : Jean-Baptiste Defard [mailto:***@defard.com]
Envoyé : mardi 22 février 2011 17:46
À : java
Objet : Re: Dialoge Process

Salut,
Ou alors en plus moderne : AMQP pour la communication. Coté Java, je sais qu'il y a un composant Camel. il existe une (au moins) implémentation AMQP en C++.
seulement 1 cent (car je n'ai pas encore eu l'occasion de tester la chose).
--
Jean-Baptiste

Le 22/02/2011 16:53, jerome moliere a écrit :
Salut erik,
moi à ta place (mais je n'y suis pas) je ferai du CORBA sur un bus même local et cela serait plus clean architecturalement et t'aurais pas de galÚres du type de celle rencontrée

My 2 cents
jerome
PS:
en plus t'as tout ce qu'il faut cÎté Java dans une JVM récente
Le 22 février 2011 16:45, Erik Mazoyer <***@uni-learning.com<mailto:***@uni-learning.com>> a écrit :
Bonjour à tous,

Dans nos développements nous avons besoin de transformer un Flash en image sous Java.
Pour cela nous avons écrit une passerelle JNI pour shooter l'animation en C++ et la récupérer en Java.
Malheureusement l'ActiveX Flash n'est pas stable dans le temps et quand il plante, il plante aussi la JVM.

Pour éviter cela, nous envisageons d'écrire un application C++ et de la lancer depuis Java.
De ce fait, si l'application plante, la JVM n'est pas perturbée.

Mais (car il y a toujours un mais) il faut mettre en place une communication entre l'application et la JVM (lancer l'application pour chaque rendu est trop consommateur de temps).
Les solutions de dialogue basées sur ip sont proscrites car l'application doit pouvoir fonctionner sur tout ordinateur avec ou sans Firewall sans que l'utilisateur n'est à modifier sa configuration (souvent il n'en a pas le droit).

J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process lancé par Java.

Pour tester cela j'ai écrit une appli C++ qui fait un écho, elle lit en permanence sur std::cin et écrit ce qu'elle lit sur std::cout.
Je l'ai testée sur l'invite de commande avec succÚs.

Du coté Java :

Process process = new ProcessBuilder(processFile.getCanonicalPath()).start();
OutputStream outputStream = process.getOutputStream();
InputStream inputStream = process.getInputStream();

Ensuite je délÚgue à des threads le remplissage de l'outputStream et la lecture de l'inputStream.
Seulement voila, je reçois bien le message de l'appli comme quoi elle s'est lancée mais j'ai beau envoyer des caractÚres sur l'outputStream, je ne reçois rien sur l'inputstream.

J'ai essayé la lib Shell d'adiGuba (com.developpez.adiguba.shell) sans que ça ne change quoi que ce soit.

Ave- vous déjà réalisé cela ?
Avez-vous des pistes de réflexions.

Merci d'avoir lu jusqu'ici :)

Erik

[Damien Lecan]

Salut,

J'ai déjà mis en oeuvre une telle architecture sur Linux pour isoler un
programme en C++ qui avait des fuites mémoires (mais qu'on avait pas le
droit de corriger).
Ca fonctionnait très, très bien.

A l'époque (2 ans), on avait utilisé la lib plexus-utils qui fournit une API
qui ressemble à la lib Shell d'adiGuba. Mais ça marchait aussi très bien
avec l'API standard du JDK quand on sait lire correctement tous les streams
en parallèle.

Il fonctionne bien en ligne de commande ton programme en C++ qui fait un
écho ?

Damien

Post by Erik Mazoyer
Bonjour à tous,
Dans nos développements nous avons besoin de transformer un Flash en image sous Java.
Pour cela nous avons écrit une passerelle JNI pour shooter l'animation en
C++ et la récupérer en Java.
Malheureusement l'ActiveX Flash n'est pas stable dans le temps et quand il
plante, il plante aussi la JVM.
Pour éviter cela, nous envisageons d'écrire un application C++ et de la
lancer depuis Java.
De ce fait, si l'application plante, la JVM n'est pas perturbée.
Mais (car il y a toujours un mais) il faut mettre en place une
communication entre l'application et la JVM (lancer l'application pour
chaque rendu est trop consommateur de temps).
Les solutions de dialogue basées sur ip sont proscrites car l'application
doit pouvoir fonctionner sur tout ordinateur avec ou sans Firewall sans que
l'utilisateur n'est à modifier sa configuration (souvent il n'en a pas le
droit).
J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process
lancé par Java.
Pour tester cela j'ai écrit une appli C++ qui fait un écho, elle lit en
permanence sur std::cin et écrit ce qu'elle lit sur std::cout.
Je l'ai testée sur l'invite de commande avec succès.
Process process = new
ProcessBuilder(processFile.getCanonicalPath()).start();
OutputStream outputStream = process.getOutputStream();
InputStream inputStream = process.getInputStream();
Ensuite je délègue à des threads le remplissage de l'outputStream et la
lecture de l'inputStream.
Seulement voila, je reçois bien le message de l'appli comme quoi elle s'est
lancée mais j'ai beau envoyer des caractères sur l'outputStream, je ne
reçois rien sur l'inputstream.
J'ai essayé la lib Shell d'adiGuba (com.developpez.adiguba.shell) sans que
ça ne change quoi que ce soit.
Ave- vous déjà réalisé cela ?
Avez-vous des pistes de réflexions.
Merci d'avoir lu jusqu'ici :)
Erik

[Erik Mazoyer]

Merci à tous pour vos réponses.

Quelques précisions :

Pourquoi Flash ? Car notre logiciel produit des animations Flash de formation qui seront regardées par les apprenants sur leur poste à travers leur navigateur. La technologie est vraiment bien dans cette utilisation et permet de produire des cours très design.

Pourquoi shooter du Flash ? Pour permettre d'avoir un Wysiwyg dans notre logiciel.

Pourquoi ne pas utiliser la couche ip ? Car nous avons déjà rencontré des postes dans les entreprises ou la couche ip est bridée (Firwall par exemple). Il faut que notre logiciel fonctionne partout :).


@Damien : J'ai déjà mis en oeuvre une telle architecture sur Linux pour isoler un programme en C++ qui avait des fuites mémoires (mais qu'on avait pas le droit de corriger). Ca fonctionnait très, très bien. Il fonctionne bien en ligne de commande ton programme en C++ qui fait un écho ?

C'est une bonne chose que tu l'ai mis en place. Bon sous Linux, je ne sais pas si sous Windows nous n'avons pas des « particularités » :).
Sinon, oui en ligne de commande ça marche.



@Hervé : Vois peut être http://www.flagstonesoftware.com/transform/index.html

Ça marche pas mal, mais il faut comprendre la structure du format flash.

Nous avons un Flash assez complexe, qui récupère des données, effectue des calculs et produit une visualisation avec gestion des transparences. Bref c'est assez compliqué de changer de techno. Mais je vais regarder Flagstone Software, nous travaillons beaucoup avec Flash et Java et ça semble une passerelle très intéressante.


@Jean-Baptiste (Briaud) : Je ne suis pas sur d'avoir bien compris ce que tu voulais faire, mais une bidouille me viens à l'esprit :
"shooter l'animation" via des captures d'écran avec awt ... ?

Le problème est que Flash n'est pas stable dans le temps. Or l'utilisation de notre outil peu durer une journée complète sans redémarrage. Et la Flash n'est pas stable du tout. De plus quand il plante, il plante gravement et plante la JVM. Impossible de catcher une exception sous C++, c'est plus grave que ça :). En fait il se prend les pieds dans le tapis avec le multi-threading.


@Baptiste : > J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process lancé par Java. C'est pas bête du tout et ça marche très bien. Preuve en est : jenkins récupère les logs de processus externe exactement comme ça. Nous on le fait ss pb ds différents cas... ... Ptete un pb ds ton code C++ qd même ?
Et ça fonctionnait sous Windows ?
Pour mon code C++, il est tout à fait possible que ça vienne de lui ou des encodages entre Java et C++. A priori j'ai tout mis en Unicode mais je suis sous Windows :).
Mais avant de chercher du coté de C++ je voulais juste savoir si quelqu'un était tombé sur un problème en utilisant cela sous Windows.


@Jean-Baptiste (Defard) : Et pour répondre à ton autre question, non jamais. L'age venant j'évite le saut à l'élastique ;-)
Surtout si l'élastique s'appelle Flash.

C'était surtout sur la communication Java <=> C++ que je te posais la question. Pour Flash nous avons des spécialistes et pas mal d'expériences (parfois douloureuses) depuis que le produit existe (environ 8 ans).

Erik

[p***@orange-ftgroup.com]

Si je comprends bien votre truc c'est pour pouvoir voir des animations flash dans des navigateurs qui ne supportent pas flash ?
M'enfin quelle idée de ne pas supporter flash ;-)

De : Erik Mazoyer [mailto:***@uni-learning.com]
Envoyé : mercredi 23 février 2011 14:44
À : Java
Objet : RE: Dialoge Process

Merci à tous pour vos réponses.

Quelques précisions :

Pourquoi Flash ? Car notre logiciel produit des animations Flash de formation qui seront regardées par les apprenants sur leur poste à travers leur navigateur. La technologie est vraiment bien dans cette utilisation et permet de produire des cours très design.

Pourquoi shooter du Flash ? Pour permettre d'avoir un Wysiwyg dans notre logiciel.

Pourquoi ne pas utiliser la couche ip ? Car nous avons déjà rencontré des postes dans les entreprises ou la couche ip est bridée (Firwall par exemple). Il faut que notre logiciel fonctionne partout :).


@Damien : J'ai déjà mis en oeuvre une telle architecture sur Linux pour isoler un programme en C++ qui avait des fuites mémoires (mais qu'on avait pas le droit de corriger). Ca fonctionnait très, très bien. Il fonctionne bien en ligne de commande ton programme en C++ qui fait un écho ?
C'est une bonne chose que tu l'ai mis en place. Bon sous Linux, je ne sais pas si sous Windows nous n'avons pas des « particularités » :).
Sinon, oui en ligne de commande ça marche.



@Hervé : Vois peut être http://www.flagstonesoftware.com/transform/index.html

Ça marche pas mal, mais il faut comprendre la structure du format flash.

Nous avons un Flash assez complexe, qui récupère des données, effectue des calculs et produit une visualisation avec gestion des transparences. Bref c'est assez compliqué de changer de techno. Mais je vais regarder Flagstone Software, nous travaillons beaucoup avec Flash et Java et ça semble une passerelle très intéressante.


@Jean-Baptiste (Briaud) : Je ne suis pas sur d'avoir bien compris ce que tu voulais faire, mais une bidouille me viens à l'esprit :
"shooter l'animation" via des captures d'écran avec awt ... ?

Le problème est que Flash n'est pas stable dans le temps. Or l'utilisation de notre outil peu durer une journée complète sans redémarrage. Et la Flash n'est pas stable du tout. De plus quand il plante, il plante gravement et plante la JVM. Impossible de catcher une exception sous C++, c'est plus grave que ça :). En fait il se prend les pieds dans le tapis avec le multi-threading.


@Baptiste : > J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process lancé par Java. C'est pas bête du tout et ça marche très bien. Preuve en est : jenkins récupère les logs de processus externe exactement comme ça. Nous on le fait ss pb ds différents cas... ... Ptete un pb ds ton code C++ qd même ?
Et ça fonctionnait sous Windows ?
Pour mon code C++, il est tout à fait possible que ça vienne de lui ou des encodages entre Java et C++. A priori j'ai tout mis en Unicode mais je suis sous Windows :).
Mais avant de chercher du coté de C++ je voulais juste savoir si quelqu'un était tombé sur un problème en utilisant cela sous Windows.


@Jean-Baptiste (Defard) : Et pour répondre à ton autre question, non jamais. L'age venant j'évite le saut à l'élastique ;-)
Surtout si l'élastique s'appelle Flash.

C'était surtout sur la communication Java <=> C++ que je te posais la question. Pour Flash nous avons des spécialistes et pas mal d'expériences (parfois douloureuses) depuis que le produit existe (environ 8 ans).

Erik


********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

[Erik Mazoyer]

Ouh la la. Visiblement je ne suis pas clair du tout !

Le contexte est le suivant :

Nous développons un logiciel en Java qui génère un cours qui se jouera en Flash.
Notre logiciel génère un moteur Flash et des fichiers annexes (XML, images, sons etc.) pour que le moteur Flash puisse diffuser le cours généré.
Tout cela marche fort bien.

Dans notre logiciel (qui est utilisé par le concepteur pédagogique et non par l'apprenant final) il est possible de placer les éléments des écrans du cours.
Afin que le placement puisse être Wysiwyg, nous shootons Flash et affichons la « photo » en Java.

Pour l'instant nous avons développé du code C++ qui shoote Flash dans une fenêtre hors écran. Et ceci à travers JNI pour que Java et C++ dialoguent tranquillement.
Hélas, l'ActiveX Flash est très mal écrit et n'est pas stable.
Du coup son plantage entraine le plantage de la JVM (du fait du JNI).

@Patrice : Si je comprends bien votre truc c'est pour pouvoir voir des animations flash dans des navigateurs qui ne supportent pas flash ?
M'enfin quelle idée de ne pas supporter flash ;-)

Non, l'apprenant doit obligatoirement avoir Flash. Le problème est juste pour faire du Wysiwyg. Notre approche implique de shooter du Flash. On ne peut pas jouer le Flash car notre moteur Flash ne fait que diffuser, il ne permet pas d'éditer (pour pleins de raison qu'il serait trop long à discuter ici).

@Jean-Baptiste (Briaud) : ... et alors ? Justement, la capture d'écran se passe dans une JVM qui n'à rien à voir avec Flash. Donc si flash plante, la JVM de capture d'écran n'est pas impactée.

La capture doit se faire hors écran. L'utilisateur ne doit pas voir des fenêtres intempestives apparaitre sur son écran.
En plus nous devons gérer les transparences. Pour ce faire on shoot deux fois, sur fond noir et sur fond blanc et on en déduit la transparence.
Je ne vois pas comment faire ça avec un copie d'écran AWT ?

Qui plus est, on doit pouvoir afficher différents rendus (celui du boutons, celui de l'image, du texte, des listes...) à des tailles différentes. Il faut donc pouvoir envoyer des infos à Flash et qu'il nous réponde quand il est prêt et enfin que l'on shoot.
Tout ça existe déjà en JNI. Il faut juste pouvoir placer cela dans une appli (préservation du process JVM) et pouvoir dialogue avec l'appli.
J'ai pensé à un système d'échange de fichiers, mais ça reste compliqué alors qu'à priori un InputStream et un OutputStream suffisent.

En fait je ne pensais pas avoir de soucis. Je pensais que le dialogue Java <=> C++ marcherait du premier coup, tellement c'est simple à imaginer

Erik


________________________________
Erik Mazoyer
Architecte, Chef de Projet
Tél : [phone] | Mob. [phone]
Mél : ***@uni-learning.com<mailto:***@uni-learning.com>
Salle Connect : http://connect.uni-learning.com/emazoyer

U&I Learning France | 8, rue Henri Becquerel | 92508 Rueil-Malmaison Cedex
Tél. [phone] | Fax [phone]| www.uni-learning.com<http://www.uni-learning.com/>
| Disclaimer | The information contained in this electronic message may be legally privileged and confidential under applicable law, and is intended only for the use of the individual or entity named above. If the recipient of this message is not the above-named intended recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify the senders mobile and purge the communication immediately without making any copy or distribution.

De : ***@orange-ftgroup.com [mailto:***@orange-ftgroup.com]
Envoyé : mercredi 23 février 2011 14:49
À : Java
Objet : RE: Dialoge Process

Si je comprends bien votre truc c'est pour pouvoir voir des animations flash dans des navigateurs qui ne supportent pas flash ?
M'enfin quelle idée de ne pas supporter flash ;-)

De : Erik Mazoyer [mailto:***@uni-learning.com]
Envoyé : mercredi 23 février 2011 14:44
À : Java
Objet : RE: Dialoge Process

Merci à tous pour vos réponses.

Quelques précisions :

Pourquoi Flash ? Car notre logiciel produit des animations Flash de formation qui seront regardées par les apprenants sur leur poste à travers leur navigateur. La technologie est vraiment bien dans cette utilisation et permet de produire des cours très design.

Pourquoi shooter du Flash ? Pour permettre d'avoir un Wysiwyg dans notre logiciel.

Pourquoi ne pas utiliser la couche ip ? Car nous avons déjà rencontré des postes dans les entreprises ou la couche ip est bridée (Firwall par exemple). Il faut que notre logiciel fonctionne partout :).


@Damien : J'ai déjà mis en oeuvre une telle architecture sur Linux pour isoler un programme en C++ qui avait des fuites mémoires (mais qu'on avait pas le droit de corriger). Ca fonctionnait très, très bien. Il fonctionne bien en ligne de commande ton programme en C++ qui fait un écho ?
C'est une bonne chose que tu l'ai mis en place. Bon sous Linux, je ne sais pas si sous Windows nous n'avons pas des « particularités » :).
Sinon, oui en ligne de commande ça marche.



@Hervé : Vois peut être http://www.flagstonesoftware.com/transform/index.html

Ça marche pas mal, mais il faut comprendre la structure du format flash.

Nous avons un Flash assez complexe, qui récupère des données, effectue des calculs et produit une visualisation avec gestion des transparences. Bref c'est assez compliqué de changer de techno. Mais je vais regarder Flagstone Software, nous travaillons beaucoup avec Flash et Java et ça semble une passerelle très intéressante.


@Jean-Baptiste (Briaud) : Je ne suis pas sur d'avoir bien compris ce que tu voulais faire, mais une bidouille me viens à l'esprit :
"shooter l'animation" via des captures d'écran avec awt ... ?

Le problème est que Flash n'est pas stable dans le temps. Or l'utilisation de notre outil peu durer une journée complète sans redémarrage. Et la Flash n'est pas stable du tout. De plus quand il plante, il plante gravement et plante la JVM. Impossible de catcher une exception sous C++, c'est plus grave que ça :). En fait il se prend les pieds dans le tapis avec le multi-threading.


@Baptiste : > J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process lancé par Java. C'est pas bête du tout et ça marche très bien. Preuve en est : jenkins récupère les logs de processus externe exactement comme ça. Nous on le fait ss pb ds différents cas... ... Ptete un pb ds ton code C++ qd même ?
Et ça fonctionnait sous Windows ?
Pour mon code C++, il est tout à fait possible que ça vienne de lui ou des encodages entre Java et C++. A priori j'ai tout mis en Unicode mais je suis sous Windows :).
Mais avant de chercher du coté de C++ je voulais juste savoir si quelqu'un était tombé sur un problème en utilisant cela sous Windows.


@Jean-Baptiste (Defard) : Et pour répondre à ton autre question, non jamais. L'age venant j'évite le saut à l'élastique ;-)
Surtout si l'élastique s'appelle Flash.

C'était surtout sur la communication Java <=> C++ que je te posais la question. Pour Flash nous avons des spécialistes et pas mal d'expériences (parfois douloureuses) depuis que le produit existe (environ 8 ans).

Erik


********************************************************************************

IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles

et peuvent etre protegees par la loi.

Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.

Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message

et tous les fichiers eventuellement attaches.

Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.

Tout message electronique est susceptible d alteration.

A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.

De meme, il appartient au destinataire de s assurer de l absence de tout virus.



IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is

intended only for the named recipient(s) above.

If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.

Any unauthorized view, usage or disclosure ofthis message is prohibited.

Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.

Additionally the recipient should ensure they are actually virus free.

********************************************************************************

[p***@orange-ftgroup.com]

C'est beaucoup plus clair.
Mais je n'ai hélas pas d'autre réponse à apporter.

Mais c'était très intéressant ;-)

Patrice

De : Erik Mazoyer [mailto:***@uni-learning.com]
Envoyé : mercredi 23 février 2011 15:25
À : Java
Objet : RE: Dialoge Process

Ouh la la. Visiblement je ne suis pas clair du tout !

Le contexte est le suivant :
[...]

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

[Jean-Baptiste BRIAUD -- Novlog]

Post by Jean-Baptiste BRIAUD -- Novlog
"shooter l'animation" via des captures d'écran avec awt ... ?
Le problème est que Flash n’est pas stable dans le temps. Or l’utilisation de notre outil peu durer une journée complète sans redémarrage. Et la Flash n’est pas stable du tout. De plus quand il plante, il plante gravement et plante la JVM. Impossible de catcher une exception sous C++, c’est plus grave que ça :). En fait il se prend les pieds dans le tapis avec le multi-threading.

... et alors ? Justement, la capture d'écran se passe dans une JVM qui n'à rien à voir avec Flash. Donc si flash plante, la JVM de capture d'écran n'est pas impactée.
Visiblement, tu as un problème mémoire (ou autre) avec flash, mais je ne vois pas pourquoi cela serait un problème avec la JVM qui shoot via les captures.
Cette solution fait plutôt appel du multiprocess qu'à du multithread.

Sinon, peux tu détailler la stack ? J'ai l'impression qu'on parle d'applet dans un navigateur ou bien n'y a t-il pas de navigateur ??
Et pourquoi pas du javascript ?

En résumé, j'ai toujours pas compris sans technique, ce que tu voulais faire avec cette animation et d'autre part, j'ai pas compris l'environnement technique sinon qu'il y avait du C++ et du Java, mais dans quel contexte ?

[Damien Lecan]

Post by Erik Mazoyer
@Damien : J'ai déjà mis en oeuvre une telle architecture sur Linux pour
isoler un programme en C++ qui avait des fuites mémoires (mais qu'on avait
pas le droit de corriger). Ca fonctionnait très, très bien. Il fonctionne
bien en ligne de commande ton programme en C++ qui fait un écho ?
C’est une bonne chose que tu l’ai mis en place. Bon sous Linux, je ne sais
pas si sous Windows nous n’avons pas des « particularités » :).
Sinon, oui en ligne de commande ça marche.

La prod était sous Linux, mais la moitié des développeurs travaillaient sous
Windows XP natif (pas de cygwin), l'autre sous Ubuntu.
Et fonctionnait pour tout le monde évidemment ;)

Bon, reprenons ton architecture :
- un programme Java qui pilote un programme en C++ qui lit stdin pour
écrire dans stdout
- échange d'information par stdin, stdout et stderr
- le thread qui est branché sur stdin du programme en C++ écrit et flush
bien le outputstream
- ton programme echo en C++ trace dans un fichier qu'il a bien reçu le flux
du Java venant de stdin
- ton programme echo en C++ trace dans un fichier qu'il a bien écrit dans
stdout
- le thread qui est branché sur stdout par un inputstream ne reçoit rien
- Même chose pour stderr

C'est bien ça ?

Damien

[Erik Mazoyer]

Bonjour à tous, merci pour vos réponse.

Vais-je oser dire que j'ai résolu mon problème grâce à Damien ?
Je suis allé chercher mon erreur dans les méandres windosiens alors qu'il manquait un Flush !!!
Une erreur triviale !

Bref merci Damien pour ta synthèse.

Et ça marche !


Erik

De : Damien Lecan [mailto:***@dlecan.com]
Envoyé : jeudi 24 février 2011 09:23
À : ***@u-strasbg.fr
Objet : Re: Dialoge Process

@Damien : J'ai déjà mis en oeuvre une telle architecture sur Linux pour isoler un programme en C++ qui avait des fuites mémoires (mais qu'on avait pas le droit de corriger). Ca fonctionnait très, très bien. Il fonctionne bien en ligne de commande ton programme en C++ qui fait un écho ?
C'est une bonne chose que tu l'ai mis en place. Bon sous Linux, je ne sais pas si sous Windows nous n'avons pas des « particularités » :).
Sinon, oui en ligne de commande ça marche.

La prod était sous Linux, mais la moitié des développeurs travaillaient sous Windows XP natif (pas de cygwin), l'autre sous Ubuntu.
Et fonctionnait pour tout le monde évidemment ;)

Bon, reprenons ton architecture :
- un programme Java qui pilote un programme en C++ qui lit stdin pour écrire dans stdout
- échange d'information par stdin, stdout et stderr
- le thread qui est branché sur stdin du programme en C++ écrit et flush bien le outputstream
- ton programme echo en C++ trace dans un fichier qu'il a bien reçu le flux du Java venant de stdin
- ton programme echo en C++ trace dans un fichier qu'il a bien écrit dans stdout
- le thread qui est branché sur stdout par un inputstream ne reçoit rien
- Même chose pour stderr

C'est bien ça ?

Damien

[Damien Lecan]

Rendons à César ce qui est à César, j'ai vu après coup que Baptiste t'avait
déjà suggéré la chose hier :)

Damien

Post by Erik Mazoyer
Bonjour à tous, merci pour vos réponse.
Vais-je oser dire que j’ai résolu mon problème grâce à Damien ?
Je suis allé chercher mon erreur dans les méandres windosiens alors qu’il
manquait un Flush !!!
Une erreur triviale !
Bref merci Damien pour ta synthèse.
Et ça marche !
Erik
*Envoyé :* jeudi 24 février 2011 09:23
*Objet :* Re: Dialoge Process
@Damien : J'ai déjà mis en oeuvre une telle architecture sur Linux pour
isoler un programme en C++ qui avait des fuites mémoires (mais qu'on avait
pas le droit de corriger). Ca fonctionnait très, très bien. Il fonctionne
bien en ligne de commande ton programme en C++ qui fait un écho ?
C’est une bonne chose que tu l’ai mis en place. Bon sous Linux, je ne sais
pas si sous Windows nous n’avons pas des « particularités » :).
Sinon, oui en ligne de commande ça marche.
La prod était sous Linux, mais la moitié des développeurs travaillaient
sous Windows XP natif (pas de cygwin), l'autre sous Ubuntu.
Et fonctionnait pour tout le monde évidemment ;)
- un programme Java qui pilote un programme en C++ qui lit stdin pour écrire dans stdout
- échange d'information par stdin, stdout et stderr
- le thread qui est branché sur stdin du programme en C++ écrit et flush
bien le outputstream
- ton programme echo en C++ trace dans un fichier qu'il a bien reçu le
flux du Java venant de stdin
- ton programme echo en C++ trace dans un fichier qu'il a bien écrit dans stdout
- le thread qui est branché sur stdout par un inputstream ne reçoit rien
- Même chose pour stderr
C'est bien ça ?
Damien

[Hervé Agnoux]

Post by Erik Mazoyer
Bonjour à tous,
Dans nos développements nous avons besoin de transformer un Flash en image
sous Java. Pour cela nous avons écrit une passerelle JNI pour shooter
l'animation en C++ et la récupérer en Java. Malheureusement l'ActiveX
Flash n'est pas stable dans le temps et quand il plante, il plante aussi
la JVM.

Vois peut être http://www.flagstonesoftware.com/transform/index.html

Ça marche pas mal, mais il faut comprendre la structure du format flash.

[Jean-Baptiste BRIAUD -- Novlog]

Je ne suis pas sur d'avoir bien compris ce que tu voulais faire, mais une bidouille me viens à l'esprit :
"shooter l'animation" via des captures d'écran avec awt ... ?

Post by Erik Mazoyer
Bonjour à tous,
Dans nos développements nous avons besoin de transformer un Flash en image sous Java.
Pour cela nous avons écrit une passerelle JNI pour shooter l'animation en C++ et la récupérer en Java.
Malheureusement l'ActiveX Flash n'est pas stable dans le temps et quand il plante, il plante aussi la JVM.
Pour éviter cela, nous envisageons d'écrire un application C++ et de la lancer depuis Java.
De ce fait, si l'application plante, la JVM n'est pas perturbée.
Mais (car il y a toujours un mais) il faut mettre en place une communication entre l'application et la JVM (lancer l'application pour chaque rendu est trop consommateur de temps).
Les solutions de dialogue basées sur ip sont proscrites car l'application doit pouvoir fonctionner sur tout ordinateur avec ou sans Firewall sans que l'utilisateur n'est à modifier sa configuration (souvent il n'en a pas le droit).
J'avais bêtement pensé à utiliser les InpuStream et OutputStream du Process lancé par Java.
Pour tester cela j'ai écrit une appli C++ qui fait un écho, elle lit en permanence sur std::cin et écrit ce qu'elle lit sur std::cout.
Je l'ai testée sur l'invite de commande avec succès.
Process process = new ProcessBuilder(processFile.getCanonicalPath()).start();
OutputStream outputStream = process.getOutputStream();
InputStream inputStream = process.getInputStream();
Ensuite je délègue à des threads le remplissage de l'outputStream et la lecture de l'inputStream.
Seulement voila, je reçois bien le message de l'appli comme quoi elle s'est lancée mais j'ai beau envoyer des caractères sur l'outputStream, je ne reçois rien sur l'inputstream.
J'ai essayé la lib Shell d'adiGuba (com.developpez.adiguba.shell) sans que ça ne change quoi que ce soit.
Ave- vous déjà réalisé cela ?
Avez-vous des pistes de réflexions.
Merci d'avoir lu jusqu'ici :)
Erik

[Baptiste MATHUS]

J'avais bêtement pensé à utiliser les InpuStream et OutputStream du

Process lancé par Java.

C'est pas bête du tout et ça marche trÚs bien. Preuve en est : jenkins
récupÚre les logs de processus externe exactement comme ça.

Nous on le fait ss pb ds différents cas.

Pour tester cela j'ai écrit une appli C++ qui fait un écho, elle lit en

permanence sur std::cin et écrit ce qu'elle lit sur std::cout.

Je l'ai testée sur l'invite de commande avec succÚs.

Ptete un pb ds ton code C++ qd même ?

Process process = new

ProcessBuilder(processFile.getCanonicalPath()).start();

OutputStream outputStream = process.getOutputStream();
InputStream inputStream = process.getInputStream();
Ensuite je délÚgue à des threads le remplissage de l'outputStream et la

lecture de l'inputStream.

Seulement voila, je reçois bien le message de l'appli comme quoi elle

s'est lancée mais j'ai beau envoyer des caractÚres sur l'outputStream, je ne
reçois rien sur l'inputstream.

J'ai essayé la lib Shell d'adiGuba (com.developpez.adiguba.shell) sans que

ça ne change quoi que ce soit.

C'est une surcouche, donc ça peut rien changer.

Ave- vous déjà réalisé cela ?

Oui, donc :).

Avez-vous des pistes de réflexions.

À tout hasard. Pb de flush qq part ?

Merci d'avoir lu jusqu'ici :)
Erik