OVH Cloud OVH Cloud

"export Display" en java

13 réponses
Avatar
rdeman
Bonjour,

J'ai un daemon =E9crit en java qui tourne sur un serveur Unix (lanc=E9
depuis un compte Admin)
Ce daemon doit r=E9pondre en socket =E0 des requetes provenant d'autres
users logu=E9s sur le m=EAme serveur (via une =E9mulation X; chacun a son
propre display).
Pour r=E9pondre =E0 ces requetes, il est parfois n=E9cessaire d'ouvrir une
IHM (swing). Il faut donc que je puisse (au sein du thread qui traite
cette requette) positionner le display du user qui a lanc=E9 requette
(il l'aura pass=E9 lors de sa connection au daemon).
1/ est-ce possible ? (est-il possible de g=E9rer plusieurs DISPLAY au
sein d'une m=EAme JVM ?)
2/ quelqu'un sait-il comment faire ?

Merci d'avance

10 réponses

1 2
Avatar
Ploc
wrote:
Bonjour,

J'ai un daemon écrit en java qui tourne sur un serveur Unix (lancé
depuis un compte Admin)
Ce daemon doit répondre en socket à des requetes provenant d'autres
users logués sur le même serveur (via une émulation X; chacun a son
propre display).
Pour répondre à ces requetes, il est parfois nécessaire d'ouvrir une
IHM (swing). Il faut donc que je puisse (au sein du thread qui traite
cette requette) positionner le display du user qui a lancé requette
(il l'aura passé lors de sa connection au daemon).
1/ est-ce possible ? (est-il possible de gérer plusieurs DISPLAY au
sein d'une même JVM ?)
2/ quelqu'un sait-il comment faire ?

Merci d'avance


Je ne suis pas sur de comprendre.
Le serveur ouvre une fenetre? Je sais pas si c'est une bonne idee.

Le plus simple serait, je pense, de faire une appli cliente separee.
Dans, ce cas, le client ouvre une connexion vers le serveur et le
serveur repond sur cette connexion dans un protocole precis.
Apres, il faut bien preciser le protocole, mais suivant les besoins, ca
peut tres bien etre un protocole connu genre HTTP (qui evite d'avoir a
ecrire un client) ou un protocole maison qui sera potentiellement plus
adapte mais qu'il faudra creer et implementer dans un client en plus du
serveur.
J'espere que ca repond a la question.

Avatar
TestMan
Bonjour,

Pouvez-vous nous en dire plus sur les besoins associés à l'IHM à ouvrir
? Qui l'utilisera ? Quel but ? Quel type d'interraction ?

Sauf erreur, la variable DISPLAY de Java est celle du processus de la VM
(process UNIX), il me parrait donc difficile d'avoir plusieurs valeurs
simmultanement, car autant je suis sur que le multidisplay marche nickel
et depuis des décénies avec du multiprocess autant je doute que le
multidisplay marche avec du multithread pour un même processus sauf à
trouver une "bidouille".

Je pense ainsi qu'un contournement vous sera nécessaire, d'où ma
question du début ...

A+
TM

Bonjour,

J'ai un daemon écrit en java qui tourne sur un serveur Unix (lancé
depuis un compte Admin)
Ce daemon doit répondre en socket à des requetes provenant d'autres
users logués sur le même serveur (via une émulation X; chacun a son
propre display).
Pour répondre à ces requetes, il est parfois nécessaire d'ouvrir une
IHM (swing). Il faut donc que je puisse (au sein du thread qui traite
cette requette) positionner le display du user qui a lancé requette
(il l'aura passé lors de sa connection au daemon).
1/ est-ce possible ? (est-il possible de gérer plusieurs DISPLAY au
sein d'une même JVM ?)
2/ quelqu'un sait-il comment faire ?

Merci d'avance



Avatar
Vincent Cantin
Ne serait-il pas plus simple que ce ne soit pas le demon qui fasse
l'affichage, mais un client ?

Vincent
Avatar
rdeman
Voici une description + détaillée de l'architecture : le but de ce
daemon est de centraliser les echanges avec une appli web (echanges en
RMI). Le Daemon est donc un client pour cette appli web (serveur J2EE).
Sur le serveur Unix, plusieurs utilisateurs sont loggés (via une
emulation X), chacun avec son propre login, sa propre ip (celle du
terminal X d'ou est lancée l'émulation) et donc son propre DISPLAY.
L'utilisateur lance sur ce serveur une application de calcul. Il en
existe plusieurs. Elles sont écrites en Perl, en C++ ou autre. Ces
applications de calcul doivent maintenant s'interfacer avec l'appli web
pour sélectionner ou stocker des données (jusqu'à maintenant, les
données étaient stockées sur le file system, maintenant, elles
doivent être stockées dans l'appi web). Pour celà, il faut monter
une IHMs, par exemple pour naviguer dans la structure de folders de
l'appli web.
- Premiere solution : développer un service web (type SOAP) côté de
l'appli web. Chacune des applications de calcul devrait donc mettre à
jour ses IHM pour utiliser cette API (en tant que client de ce service
web) de bas niveau (par exemple, une API pour naviguer dans la
structure de folders de l'appli web).
- Deuxieme solution qui me semble nettement plus judicieuse : déployer
un daemon qui offre 2 services : une API de haut niveau (selectionner
une donnée ou un folder) en socket (utilisable depuis n'importe quel
langage) et des écrans déjà tout prêts (pour aller naviguer dans la
structure de folders). Cela évite de développer le même type
d'écran dans chacune des applications de calcul. Ils sont développés
une fois pour toute dans le daemon java. Autres avantages, le daemon
est lancé une fois pour toute; il peut optimiser les accès au serveur
web et par exemple conserver des données en cache, ...
Je pourrais lancer une instance de ce daemon pour chaque utilisateur
connecté au serveur unix, mais vu ce que bouffe une JVM, je
préfèrerai le lancer une seule fois. J'ai donc besoin de gérer au
sein de la même JVM le display de plusieurs utilisateurs.

Pour info, j'ai trouvé sur SDN un bug qui correspond à mon besoin
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_idF70851
) , mais il est resté ouvert depuis 2002 ...

J'espère que c'est plus clair cette fois ...
Avatar
Rémy
"TestMan" a écrit dans le message de news:
44251f39$0$7093$
Bonjour,

Pouvez-vous nous en dire plus sur les besoins associés à l'IHM à ouvrir ?
Qui l'utilisera ? Quel but ? Quel type d'interraction ?

Sauf erreur, la variable DISPLAY de Java est celle du processus de la VM
(process UNIX), il me parrait donc difficile d'avoir plusieurs valeurs
simmultanement, car autant je suis sur que le multidisplay marche nickel
et depuis des décénies avec du multiprocess autant je doute que le
multidisplay marche avec du multithread pour un même processus sauf à
trouver une "bidouille".




Si,si aucun problème dans le principe. J'ai codé plusieurs programmes
multi-display.

Le tout est de ne pas utiliser la variable DISPLAY justement, mais de passer
le nom du display au moment où l'on fait le XOpenDisplay. (en fait, ce n'est
que lorsqu'on fait XOpenDisplay() sans paramètre que la variable DISPLAY est
recherchée).

Notez que le XOpenDisplay est généralement encapsulé dans la librairie
graphique utilisée (Xt, Motif, ...) et qu'il est possible que certaines ne
fournissent pas l'API pour renseigner le display lors de la connexion.

Par contre est-ce possible depuis un programme Java ? Je n'ai jamais essayé.
Il faudrait rechercher dans le documentation Swing (en l'occurence) s'il y a
un moyen autre que DISPLAY de spécifier le display...

Rémy


Rémy

Avatar
rdeman
Ben justement, mon pb est que je ne trouve pas l'équivalent de la
methode XOpenDisplay dans l'API java.
- existe-t-il et c'est moi qu ne l'ai pas trouvé ?
- s'il n'existe pas, et si je dois développer un conposant en C pour y
accéder, cela implique-t-il que je dois développer mes IHMs en C
également (donc finallement, mon Daemon tout entier) ?
J'aimerais développer les IHMs en java car celà m'assure une
meilleure portabilité / réutilisabilité du code.
Avatar
Rémy
a écrit dans le message de news:

Ben justement, mon pb est que je ne trouve pas l'équivalent de la
methode XOpenDisplay dans l'API java.
- existe-t-il et c'est moi qu ne l'ai pas trouvé ?


Il semble en effet que Swing sait utiliser plusieurs écrans sur une même
machine, mais pas des écrans distants.

C'est logique dans la mesure où cette fonctionnalité ne peut pas être
assurée sur tous les OS (Windows par exemple), et donc ne serait pas
portable.

- s'il n'existe pas, et si je dois développer un conposant en C pour y
accéder, cela implique-t-il que je dois développer mes IHMs en C
également (donc finallement, mon Daemon tout entier) ?


Quitte à faire du non portable, il est en effet possible de développer cette
fonctionnalité dans une librairie C ou C++ et d'y accéder depuis le Java en
JNI.

J'aimerais développer les IHMs en java car celà m'assure une
meilleure portabilité / réutilisabilité du code.


De toute façon, la fonctionnalité d'affichage distant n'existe pas sur tous
les OS. Elle ne peut donc pas être portable.

Dans ce cas, il faudrait plutôt développer les IHM côté client et que le
daemon se contente d'envoyer des messages vers les clients.

Normalement, un déemon ne devrait pas avoir des IHM complexes (au maximun
des boîtes d'erreur / mot de passe)...

Avatar
rdeman
Effectivement, je comprend bien que la librairie java que je recherche
ne marcherait que sur X11 ...

Sur 'comp.lang.java.programmer', qqun m'a envoyé un lien vers
http://escher.sourceforge.net/. A voir ...

Merci pour ce feeback.
Rodolphe
Avatar
rdeman
J'ai testé http://escher.sourceforge.net/ et ca résoud mon probleme.

Merci pour vos réponses
Rodolphe
Avatar
rdeman
Euh, enfin, non, ca ne résoud pas du tout mon pb car ca ne permet pas
d'ouvrir une fenêtre awt ou swing sur 2 terminaux X11 différents
depuis la même JVM. C'est une API de bas niveau à partir de laquelle
il faut tout redévelopper ...
Et même un truc simple comme un JTree, ca va me couter bonbon !!
1 2