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 ?
Bonjour, Je résumerer votre situation en là célèbre citation : « Lorsque le seul outil dont vous disposez est un marteau, tout finit par ressembler à un clou ».
Pourquoi ne pas demander aux application d'évoluer simplement et d'accepter de recevoir une URL WebDAV ? C'est un protocole dont la majorité des langages ont des API disponible.
Cette URL pourrait très bien être indiquée à l'utilisateur dans l'appli web et l'utilisateur n'aurait qu'à la reporter dans les interfaces s'ouvrant (en ligne de commande ou dans un champ prévu à cet effet).
Celà me semble plus simple que de réécrire un client X non ;-)
En terme d'arch et plus long terme il me semble que les différentes applications devrait être sous le seul controle (direct ou indirect de l'appli web ou une autre appli web assurant le déclenchement/suivit/arret des traitements via le web en évitant les va-et-vient compliqués... mais je vous dis ça par rapport aux éléments dont je dispose.
A+
TM
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 ...
Bonjour,
Je résumerer votre situation en là célèbre citation : « Lorsque le seul
outil dont vous disposez est un marteau, tout finit par ressembler à un
clou ».
Pourquoi ne pas demander aux application d'évoluer simplement et
d'accepter de recevoir une URL WebDAV ? C'est un protocole dont la
majorité des langages ont des API disponible.
Cette URL pourrait très bien être indiquée à l'utilisateur dans l'appli
web et l'utilisateur n'aurait qu'à la reporter dans les interfaces
s'ouvrant (en ligne de commande ou dans un champ prévu à cet effet).
Celà me semble plus simple que de réécrire un client X non ;-)
En terme d'arch et plus long terme il me semble que les différentes
applications devrait être sous le seul controle (direct ou indirect de
l'appli web ou une autre appli web assurant le
déclenchement/suivit/arret des traitements via le web en évitant les
va-et-vient compliqués... mais je vous dis ça par rapport aux éléments
dont je dispose.
A+
TM
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 ...
Bonjour, Je résumerer votre situation en là célèbre citation : « Lorsque le seul outil dont vous disposez est un marteau, tout finit par ressembler à un clou ».
Pourquoi ne pas demander aux application d'évoluer simplement et d'accepter de recevoir une URL WebDAV ? C'est un protocole dont la majorité des langages ont des API disponible.
Cette URL pourrait très bien être indiquée à l'utilisateur dans l'appli web et l'utilisateur n'aurait qu'à la reporter dans les interfaces s'ouvrant (en ligne de commande ou dans un champ prévu à cet effet).
Celà me semble plus simple que de réécrire un client X non ;-)
En terme d'arch et plus long terme il me semble que les différentes applications devrait être sous le seul controle (direct ou indirect de l'appli web ou une autre appli web assurant le déclenchement/suivit/arret des traitements via le web en évitant les va-et-vient compliqués... mais je vous dis ça par rapport aux éléments dont je dispose.
A+
TM
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 ...
rdeman
Effectivement, à terme, les applis de calcul auront leur interface intégrées dans l'appli web. Seuls les calculs batch seront réellement lancés sur le serveur de calcul sous le controle de l'appli web. Il s'agit donc ici de mettre en place une solution provisoire (intégration rapide des applis de calcul) à moindre coût. L'utilisateur a 2 fenêtres ouvertes : un web browser sur l'appli web et une emulation X. Il sélectionne son application de calcul dans l'appli web et elle est executée dans son emulateur X sous le contrôle de l'appli web (qui gère aussi la mise à disposition, le transfert et la réintégration des fichiers de données de l'appli web vers le serveur de calcul).
Je vais regarder webdav, mais ca m'a l'air vraiement destiné à la gestion de fichiers. Dans mon cas, je veux accéder à des infos (structure de folder et attributs fonctionnels associés) qui sont stockées en base de données (via l'appli web).
Effectivement, à terme, les applis de calcul auront leur interface
intégrées dans l'appli web. Seuls les calculs batch seront
réellement lancés sur le serveur de calcul sous le controle de
l'appli web.
Il s'agit donc ici de mettre en place une solution provisoire
(intégration rapide des applis de calcul) à moindre coût.
L'utilisateur a 2 fenêtres ouvertes : un web browser sur l'appli web
et une emulation X. Il sélectionne son application de calcul dans
l'appli web et elle est executée dans son emulateur X sous le
contrôle de l'appli web (qui gère aussi la mise à disposition, le
transfert et la réintégration des fichiers de données de l'appli web
vers le serveur de calcul).
Je vais regarder webdav, mais ca m'a l'air vraiement destiné à la
gestion de fichiers. Dans mon cas, je veux accéder à des infos
(structure de folder et attributs fonctionnels associés) qui sont
stockées en base de données (via l'appli web).
Effectivement, à terme, les applis de calcul auront leur interface intégrées dans l'appli web. Seuls les calculs batch seront réellement lancés sur le serveur de calcul sous le controle de l'appli web. Il s'agit donc ici de mettre en place une solution provisoire (intégration rapide des applis de calcul) à moindre coût. L'utilisateur a 2 fenêtres ouvertes : un web browser sur l'appli web et une emulation X. Il sélectionne son application de calcul dans l'appli web et elle est executée dans son emulateur X sous le contrôle de l'appli web (qui gère aussi la mise à disposition, le transfert et la réintégration des fichiers de données de l'appli web vers le serveur de calcul).
Je vais regarder webdav, mais ca m'a l'air vraiement destiné à la gestion de fichiers. Dans mon cas, je veux accéder à des infos (structure de folder et attributs fonctionnels associés) qui sont stockées en base de données (via l'appli web).
TestMan
Effectivement, à terme, les applis de calcul auront leur interface intégrées dans l'appli web. Seuls les calculs batch seront réellement lancés sur le serveur de calcul sous le controle de l'appli web. Il s'agit donc ici de mettre en place une solution provisoire (intégration rapide des applis de calcul) à moindre coût. L'utilisateur a 2 fenêtres ouvertes : un web browser sur l'appli web et une emulation X. Il sélectionne son application de calcul dans l'appli web et elle est executée dans son emulateur X sous le contrôle de l'appli web (qui gère aussi la mise à disposition, le transfert et la réintégration des fichiers de données de l'appli web vers le serveur de calcul).
Je vais regarder webdav, mais ca m'a l'air vraiement destiné à la gestion de fichiers. Dans mon cas, je veux accéder à des infos (structure de folder et attributs fonctionnels associés) qui sont stockées en base de données (via l'appli web).
Bjr,
Je ne vois comme solution à cours terme pour vous de lancer un fork de VM par appli qui sera configuré avec le bon display (ah les joies des script shell)...
Dans webdav vous pouvez stocker des méta informations, et il y a fort à parier que dans slide il est possible de connecter ses propres informations dynamiquement depuis une base en codant un "morceau de cole".
Pour info, webdav est utiliser par MS pour l'accès HTTP de Outlook, et il fait : mail, calendrier, etc ... sans PB ;-)
A+
TM
Effectivement, à terme, les applis de calcul auront leur interface
intégrées dans l'appli web. Seuls les calculs batch seront
réellement lancés sur le serveur de calcul sous le controle de
l'appli web.
Il s'agit donc ici de mettre en place une solution provisoire
(intégration rapide des applis de calcul) à moindre coût.
L'utilisateur a 2 fenêtres ouvertes : un web browser sur l'appli web
et une emulation X. Il sélectionne son application de calcul dans
l'appli web et elle est executée dans son emulateur X sous le
contrôle de l'appli web (qui gère aussi la mise à disposition, le
transfert et la réintégration des fichiers de données de l'appli web
vers le serveur de calcul).
Je vais regarder webdav, mais ca m'a l'air vraiement destiné à la
gestion de fichiers. Dans mon cas, je veux accéder à des infos
(structure de folder et attributs fonctionnels associés) qui sont
stockées en base de données (via l'appli web).
Bjr,
Je ne vois comme solution à cours terme pour vous de lancer un fork de
VM par appli qui sera configuré avec le bon display (ah les joies des
script shell)...
Dans webdav vous pouvez stocker des méta informations, et il y a fort à
parier que dans slide il est possible de connecter ses propres
informations dynamiquement depuis une base en codant un "morceau de cole".
Pour info, webdav est utiliser par MS pour l'accès HTTP de Outlook, et
il fait : mail, calendrier, etc ... sans PB ;-)
Effectivement, à terme, les applis de calcul auront leur interface intégrées dans l'appli web. Seuls les calculs batch seront réellement lancés sur le serveur de calcul sous le controle de l'appli web. Il s'agit donc ici de mettre en place une solution provisoire (intégration rapide des applis de calcul) à moindre coût. L'utilisateur a 2 fenêtres ouvertes : un web browser sur l'appli web et une emulation X. Il sélectionne son application de calcul dans l'appli web et elle est executée dans son emulateur X sous le contrôle de l'appli web (qui gère aussi la mise à disposition, le transfert et la réintégration des fichiers de données de l'appli web vers le serveur de calcul).
Je vais regarder webdav, mais ca m'a l'air vraiement destiné à la gestion de fichiers. Dans mon cas, je veux accéder à des infos (structure de folder et attributs fonctionnels associés) qui sont stockées en base de données (via l'appli web).
Bjr,
Je ne vois comme solution à cours terme pour vous de lancer un fork de VM par appli qui sera configuré avec le bon display (ah les joies des script shell)...
Dans webdav vous pouvez stocker des méta informations, et il y a fort à parier que dans slide il est possible de connecter ses propres informations dynamiquement depuis une base en codant un "morceau de cole".
Pour info, webdav est utiliser par MS pour l'accès HTTP de Outlook, et il fait : mail, calendrier, etc ... sans PB ;-)
