Discussion :

[legzo]

Bonjour à tous, voilà enfin mon premier post ici après moultes heures de consultation passive (merci au passage pour la qualité du site et du forum qui m'ont déjà bien aidé par le passé).

Voilà mon problème.

Je developpe une IHM en Java et cette IHM doit pouvoir lancer une application qui est sur une machine distante (pour l'instant cette appli est lancée via un XTerm). Déjà ça je sais pas le faire... une appli externe locale ok, j'ai trouvé dans la faq, mais distante... La deuxieme donnée du probleme est que je dois récupérer les lignes qui s'affichent dans la console distante. (oui c'est coton).

Pour donner un peu plus d'infos: la machine distante est une machine Solaris et sur réseau local. L'appli distante est un truc codé en C qui crache des logs en console et moi il faut que je traite ces logs en question.

J'espère que j'ai été à peu près clair. Je vous remercie d'avance!

(sinon oui, j'ai pensé à mettre directement mon appli sur la machine distante et à la lancer elle même dans un Xterm, mais ça rame affreusement et je pense pas que ce soit jouable à terme).

[legzo]

Non? Ca vous inspire pas mon histoire?

Ca m'embete bien, j'ai pas progressé dans mes recherches moi... C'est vrai que c'est tordu comme problème..

[Alwin]

Il n'est pas possible d'appeler un process remote en java. Le plus simple reste de faire un petit daemon qui tourne sur la machine distante et que tu invoque en tcp ou rmi.
Ce daemon pourras lancer le process et intercerpter les entrées sorties pour te les restituer par la suite.

[nicolas581]

Salut,

La machine distante permet la gestion de log. L'affichage de ces logs se fait uniquement sur un terminal ?
L'appli en C ne devrait pas afficher bêtement sur un terminal mais plutôt écrire dans des fichiers. Ensuite ton programme Java devrait devrait avoir accès à ces fichiers. Pour celà il faudrait un programme serveur qui transmette ces données au client. Si les fichiers sont gros il ne faut pas transmettre ces fichiers sur le réseau, il faut faire le traitement côté serveur et juste envoyer les résultats.
Je traiterai donc ce problème par une mise en place client/serveur.
A près client lourd ou léger tout dépend de ta philosophie

Bon courage.

[legzo]

Ok, merci bien pour ces premières pistes.

En fait, le prog en C distant crache à la fois des logs console et des logs dans un fichier. Le probleme c'est qu'il faudrait que je récupère les logs console (qui arrivent au fil de l'eau) quasiment en temps réel pour leur appliquer un traitement.

J'aime assez l'idée d'Alwin (je n'y avais pas pensé), en lançant sur ma machine Solaris un pti démon qui m'enverrai par socket les infos au fur et à mesure je pourrai peut etre m'en tirer.. Reste à plancher la dessus...

[Mobius]

Si ton appli lance un xterm comme une application externe et que xterm lance l'appli distante via SSH ou telnet, tu peux recup la sortie standard de xterm pour avoir les traces de ton appli distante.
je sais pas si c'est tres clair mais ca me parait pas tres compliqué.
si ca ne marche pas c'est surement que j'ai du louper une donnée du pb :s

[legzo]

Si ton appli lance un xterm comme une application externe et que xterm lance l'appli distante via SSH ou telnet, tu peux recup la sortie standard de xterm pour avoir les traces de ton appli distante.
je sais pas si c'est tres clair mais ca me parait pas tres compliqué.
si ca ne marche pas c'est surement que j'ai du louper une donnée du pb :s

Oui mais l'idée en fait c'est de ne plus "voir" la fenêtre xterm, de tout faire avec une IHM java. Sinon tu pensais à chopper les OutputStream de xterm en tant que Proc? Et de lancer mon truc a distance en écrivant sur le flux d'entrée? Je sais pas trop comment ça marche tout ça.

Sinon je repense au terme de démon qui a été utilisé plus tôt et je sais pas trop si c'est ce dont j'ai besoin, ce serait plutôt une petite appli sans interface côté Solaris. Parce que la fonction première du démon est bien de rester en fond même quand l'appli est fermée non? Mais là encore il faut ouvrir un xterm pour lancer ce java distant.. On en sort pas Mais c'est quand même une bonne piste, ça se rapproche le plus de ce que je veux idéalement.

[Mobius]

En fait, la solution ne serait pas de lancer xterm mais d'executer directement un script.
Je supose que tu es sous linux (si tu parles de Xterm) donc il faut que tu trouve exactement comment lancer ta commande a distance en une seule ligne de commande
par ex: "ssh -l username serveur_distant < un_fichier_contenant_la_ligne_de_commande_a_lancer"
le seul pb de cette methode c'est que ca te demandera d'entrer un mot de passe correspondant a l'utilisateur sur le site distant.
j'espere que cela repond a tes questions

Edit: La methode doit aussi pouvoir marcher sous windows

[legzo]

j'espere que cela repond a tes questions

Oui oui, ça me fait bien progresser.

J'apporte encore quelques précisions:

En fait les postes sur lesquels vont être lancés l'IHM sont sous Windows (xterm via Exceed), mais pourront basculer sous linux n'importe quand. De même la machine distante est solaris, mais là encore ça peut changer.

Je pense m'orienter vers cette solution:

Une petite appli java distante en ligne de commande à lancer une fois par jour par exemple via exceed. Cette appli java écoute sur un port particulier et permet de transmettre des commandes entrées dans l'IHM (locale) à la machine distante. Et cette appli restransmet également ce qui sort de la sortie standard à mon IHM.

Ca ca me parait pas mal.

[legzo]

Hop me revoici, j'ai bien avancé mais me voilà confronté à un autre probleme.

J'ai fait un système client/serveur avec comme client mon IHM et comme serveur un pti truc en ligne de commande qui recoit et envoit des messages. Ce server comme dit précédemment est sur une machine Solaris. Mon problème est que j'arrive pas à lancer de processes distants quand je passe sous Solaris.

Quand je fais un client sur win et un serveur sur win je n'ai pas de souci.
Quand j'échange des messages entre le client win et le server solaris je n'ai pas de souci.
Quand je lance la commande que je veux exécuter ("a2t start") via un terminal, je n'ai pas de souci.

C'est juste quand je veux lancer un process depuis mon truc java en fait. Voilà l'erreur:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
INFO: Action received: commandLine=a2t start (<< ça c'est mon logger qui me dit que la commande "a2t start" a été reçue)
java.io.IOException: a2t: not found
        at java.lang.UNIXProcess.forkAndExec(Native Method)
        at java.lang.UNIXProcess.<init>(UNIXProcess.java:56)
        at java.lang.Runtime.execInternal(Native Method)
        at java.lang.Runtime.exec(Runtime.java:566)
        at java.lang.Runtime.exec(Runtime.java:428)
        at java.lang.Runtime.exec(Runtime.java:364)
        at java.lang.Runtime.exec(Runtime.java:326)
        at transmitter.Client.cmdExec(Comm.java:197)
        at transmitter.Client.treatMessage(Comm.java:163)
        at transmitter.Client.run(Comm.java:181)

Mon code qui exécute le process est le suivant:

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
public void cmdExec(String cmdline) {
		try {
			String line;
			Process p = Runtime.getRuntime().exec(cmdline);
			BufferedReader input = 
				new BufferedReader
				(new InputStreamReader(p.getInputStream()));
			while ((line = input.readLine()) != null) {
				System.out.println(line);
			}
			input.close();
		} 
		catch (Exception err) {
			err.printStackTrace();
		}
	}

Je suis preneur de toutes les pistes parce que là je sais pas trop comment m'en sortir.. Merci d'avance.

[Mobius]

Quand je lance la commande que je veux exécuter ("a2t start") via un terminal, je n'ai pas de souci.

C'est juste quand je veux lancer un process depuis mon truc java en fait. Voilà l'erreur:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
INFO: Action received: commandLine=a2t start (<< ça c'est mon logger qui me dit que la commande "a2t start" a été reçue)
java.io.IOException: a2t: not found
        at java.lang.UNIXProcess.forkAndExec(Native Method)
        at java.lang.UNIXProcess.<init>(UNIXProcess.java:56)
        at java.lang.Runtime.execInternal(Native Method)
        at java.lang.Runtime.exec(Runtime.java:566)
        at java.lang.Runtime.exec(Runtime.java:428)
        at java.lang.Runtime.exec(Runtime.java:364)
        at java.lang.Runtime.exec(Runtime.java:326)
        at transmitter.Client.cmdExec(Comm.java:197)
        at transmitter.Client.treatMessage(Comm.java:163)
        at transmitter.Client.run(Comm.java:181)

c'est surement que quand tu lance ta commande depuis un shell, la commande est dans ton PATH alors qu'elle ne doit pas l'être quand tu lance la commande en Java. Cela expliquerai pourquoi tu n'arrive pas a lancer la commande depuis ton serveur. Pour verifier ca, regarde que contient ton PATH juste avant de lancer ton serveur.

[legzo]

c'est surement que quand tu lance ta commande depuis un shell, la commande est dans ton PATH alors qu'elle ne doit pas l'être quand tu lance la commande en Java. Cela expliquerai pourquoi tu n'arrive pas a lancer la commande depuis ton serveur. Pour verifier ca, regarde que contient ton PATH juste avant de lancer ton serveur.

Et le cas échéant je réécris dans mon PATH pour pouvoir la trouver facilement c'est ça?

Ca par contre c'est ballot: il me reconnait pas la commande pour sourcer mon .profile... il me trouve pas la commande export non plus...

[Mobius]

en fait je vois pas bien comment tu peux faire.
Je vois bien pourquoi il y a l'erreur mais je n'ai pas vraiment d'idée pour la résoudre.
il faut que t'essaye different truc par toi meme pour essayer d'ameliorer.
Je suis dsl de ne pas trop pouvoir t'aider mais je ne suis encore jamais tombé sur ce pb donc je n'ai pas de solution toute prete :s
bon courage

[legzo]

Ouaip bin je vais essayer en effet! Je suis entouré d'informaticiens en même temps donc peut etre que quelqu'un va pouvoir m'aider quand même..

thx en tout cas!

[legzo]

Allez hop je vous re-sollicite parce que je suis toujours plus ou moins dans la mouise:

il s'avère que pour que ça fonctionne, il faut que je lance un executable, et comme mon programme était un shell ça marchait pas.

J'y remédie en exectuant la chose comme ça:

Code :

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

Process p = Runtime.getRuntime().exec("ksh a2t.sh go");

ce qui fait que je me retrouve avec deux processes dans mon unix après (un bash et un ksh). Mais j'ai encore quelques problèmes: une fois mon programme lancé (bon déjà il affiche pas tous les messages de debug, je ne sais pas pourquoi), mon serveur ne peut plus exécuter d'autres commandes, il ne répond plus..

Je ne sais pas trop comment m'en sortir..

[Mobius]

comme mon programme était un shell ça marchait pas.

J'y remédie en exectuant la chose comme ça:

Code :

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

Process p = Runtime.getRuntime().exec("ksh a2t.sh go");

tu peux aussi rajouter cette ligne au début de ton script :

#!/usr/ksh

(tu dois changer /usr/ksh par l'endrois reel ou est installé ksh)

une fois mon programme lancé (bon déjà il affiche pas tous les messages de debug, je ne sais pas pourquoi), mon serveur ne peut plus exécuter d'autres commandes, il ne répond plus..

Aucune idée pour le moment mais ca doit etre con.
pour tes messages de log essaye de savoir quel sont ceux qui sont affiché et ceux qui ne le sont pas.

[legzo]

Yep, j'ai un peu avancé de ce côté là.

En fait mes problèmes de non-réactivité de mon serveur venait du fait que je perdais la main dès que je lançais une commande. En créant une nouvelle classe étendant Thread et m'exécutant mes commandes, tout va bien mieux. Je peux passer plusieurs commandes à la suite.

Pour le problème concernant le fait que certains messages apparaissaient et pas d'autres, j'ai un peu honte, mais c'est tout simplement que certains messages émanaient d'"echos" et d'autres de "printf" et je choppe que ce qui vient d'un "echo" (et d'ailleurs ça ne m'arrange pas pour mon traitement mais c'est une autre histoire...).

Merci en tout cas pour ton intérêt au sujet, ça fait plaisir!

Comme je ne manquerais pas d'être confronté à un autre problème sous peu, stay tuned