Différencier la demande de fermeture via une interface et via un taskkill

Version imprimable

19/09/2013, 16h45
Epiliptik

Différencier la demande de fermeture via une interface et via un taskkill

Bonjour,

N'ayant pas trouvé grand chose sur ce sujet sur internet et ne sachant comment faire je viens vers vous pour le problème suivant:
- serait-il possible de différencier la demande de fermeture d'une fenêtre (ou application RCP) suivant qu'elle soit faîte via l'interface ou via un signal windows envoyé avec taskkill?

L'idée serait que l'appli se ferme sans demande de message de confirmation si la demande est faîte en ligne de commande avec un taskkill (sans forcer le fermeture) et de présenter un message de confirmation si la fermeture est lancée via l'interface!

(Sous Windows évidemment^^)

Salut,

Lorsque tu vas essayer de fermer ton application via l'interface, tu vas forcement appuyer quelque part et donc générer un event.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
 
class FrameByeBye {
 
    // The method we wish to call on exit.
    public static void showDialog(Component c) {
        JOptionPane.showMessageDialog(c, "Bye Bye!");
    }
 
    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
 
                final JFrame f = new JFrame("Say Bye Bye!");
                f.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
                f.addWindowListener( new WindowAdapter() {
                    @Override
                    public void windowClosing(WindowEvent we) {
                        showDialog(f);
                        System.exit(0);
                    }
                } );
                f.setSize(300,200);
                f.setLocationByPlatform(true);
                f.setVisible(true);
 
            }
        });
    }
}

Terminer ton programme en ligne de commande ne t'affichera rien par définition puisque tu vas forcer le processus à se fermer.

Cdt.

23/09/2013, 16h19
Epiliptik

Bonjour,

Merci de ta réponse, l'idée d'utiliser le listener comme ça est bonne mais j'utilise actuellement eclipse rcp et la fermeture de la fenêtre déclenche une méthode preWindowShellClose(), c'est dans cette méthode qu'une fenêtre de confirmation s'affiche.

Je suis en train de chercher mais je n'ai toujours pas trouvé comment mettre une sorte de listener sur la fermeture de la fenêtre!
23/09/2013, 17h06
Nico02

Ça ne change rien au problème.

Tu travailles un environnement qui t'es propre, donc tu dois adapter la solution à ton travail.

L'idée reste que il y à forcément un événement qui est généré lorsque tu appuis quelque part ( sur le bouton de fermeture ou autre ça ne change rien ).
Donc à toi de l'identifier et d'écrire le code de fermeture à l'intérieur (avec appel d'une boite de confirmation si tu le souhaites ).

Cdt.
24/09/2013, 11h24
Epiliptik

Oui je sais bien, le problème c'est que la fermeture avec un taskkill ou avec l'icône en haut à droite appelle la même fonction preWindowShellClose() ... Je ne trouve pas de différence entre les 2 types de fermeture dans une appli rcp.
24/09/2013, 12h29
joel.drigo

Salut,

pas évident de différencier les différentes façons de fermer l'application (on pourrait la fermer également par un menu en plus du bouton en haut à droite), dans la mesure ou toutes passent par un évenement traité par la boucle évenementielle de SWT, y compris le taskkill "soft" qui doit envoyer simplement un évènement à l'application pour qu'elle se ferme.

On doit pouvoir différencier les sources dans l'écouteur d'évenement, mais il faudrait soit redéfinir la WorkbenchWindow (ce qui n'est pas possible à ma connaissance), soit peut être intercepter un de ses services pour détecter que la fermeture se fait pas une action du workbench pour la différencier d'un signal de l'OS... mais pas évident de l'intercepter "avant" la prise en compte de l'évenement de fermeture du workbench à priori : il faudrait tester...

J'ai un peu regardé les stacktraces dans les deux cas, et il semble qu'elles soient légèrement différentes. Je ne sais pas si c'est le fruit du hasard, ou propre à mon environnement, ou autre, mais tu peux peut être exploiter cette différence, en cherchant si tu peux déterminer si l'appel passe par une classe dans un cas, et jamais dans l'autre.

Dans le cas d'un kill j'ai :

Citation:

at org.eclipse.swt.widgets.Display.windowProc(Display.java:4619)
at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:2976)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3498)

Dans le cas d'un close j'ai :

Citation:

at org.eclipse.swt.widgets.Display.windowProc(Display.java:4619)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2411)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3501)

Sinon, question, pourquoi ne pas afficher le dialogue lors d'un taskkill ? est ce que ton but est de pouvoir fermer "silencieusement" ton appli en ligne de commande ? Si c'est le cas, tu peux peut être prévoir plus simplement une commande de fermeture que tu pourrais contrôler du coup (et donc simplement utiliser un booléen pour savoir qu'on est passé par cette commande pour fermer l'application)...
24/09/2013, 12h31
joel.drigo

Citation:

Envoyé par Nico02

Ça ne change rien au problème.

Tu travailles un environnement qui t'es propre, donc tu dois adapter la solution à ton travail.

L'idée reste que il y à forcément un événement qui est généré lorsque tu appuis quelque part ( sur le bouton de fermeture ou autre ça ne change rien ).
Donc à toi de l'identifier et d'écrire le code de fermeture à l'intérieur (avec appel d'une boite de confirmation si tu le souhaites ).

Cdt.

Salut,

ce serait vrai dans une application écrite complètement soit même, mais là, il s'agit d'une application montée sur un framework (en l'occurence, Eclipse RCP), dans lequel tu peux pas faire tout ce que tu veux malheureusement.
24/09/2013, 13h07
Nico02

Citation:

Envoyé par joel.drigo

Salut,

ce serait vrai dans une application écrite complètement soit même, mais là, il s'agit d'une application montée sur un framework (en l'occurence, Eclipse RCP), dans lequel tu peux pas faire tout ce que tu veux malheureusement.

Effectivement je viens de voir ça. Je n'ai jamais vraiment travailler avec éclipse RCP donc je ne connais pas vraiment son mode de fonctionnement, et malheureusement je n'ai pas vraiment le temps de faire des tests en ce moment..

Désolé Epiliptik ;)
24/09/2013, 17h58
Epiliptik

Ouep effectivement je voudrai pouvoir la fermer en ligne de commande à distance (donc sans interface, d'où mon problème) et sans forcer l'arrêt. Je ne comprend pas trop ta dernière proposition:

"Si c'est le cas, tu peux peut être prévoir plus simplement une commande de fermeture que tu pourrais contrôler du coup (et donc simplement utiliser un booléen pour savoir qu'on est passé par cette commande pour fermer l'application)... "

Le problème reste de savoir si l'utilisateur a fermé l'appli avec l'interface ou si elle a été fermée en ligne de commande.
24/09/2013, 18h46
joel.drigo

Citation:

Envoyé par Epiliptik

Ouep effectivement je voudrai pouvoir la fermer en ligne de commande à distance (donc sans interface, d'où mon problème) et sans forcer l'arrêt. Je ne comprend pas trop ta dernière proposition:

"Si c'est le cas, tu peux peut être prévoir plus simplement une commande de fermeture que tu pourrais contrôler du coup (et donc simplement utiliser un booléen pour savoir qu'on est passé par cette commande pour fermer l'application)... "

Le problème reste de savoir si l'utilisateur a fermé l'appli avec l'interface ou si elle a été fermée en ligne de commande.

Je voulais parler de donner la possibilité à ton appli d'être pilotée par une commande externe. J'avais trouvé il y a longtemps un blog qui parlait d'un plugin qui permettait de scripter une application RCP depuis un batch, mais le blog n'existe plus malheureusement, et je ne me souviens plus du tout de son nom :oops:

Sinon j'ai implémenté personnellement la chose avec un petit serveur http interne, qui te permet d'envoyer des commandes à ton RCP : avec un système similaire, tu pourrais faire une commande de fermeture qui te permet de fermer ton appli en ligne de commande (par wget). Mais tu peux faire ça en UDP pour te simplifier le truc, ou avec une socket toute simple. Il y a plein d'autre méthodes d'ailleurs (serveur rmi, dossier spoolé avec notif système, etc...)

Tu prévoies un signal de stop (une commande) et sur réception de ce signal, tu appelles IWorkbench.shutdown(), après avoir positionné un booléen (ou autre) pour indiquer que l'ordre de shutdown et consécutif à une commande externe. Dans l'advisor, dans la méthode preWindowShellClose(), tu n'as plus qu'à lire ce booléen.

Tu peux également "encapsuler" le traitement d'arrêt dans un service windows( au démarrage de ton appli tu installes ton service en lui passant le port de ta socket, et la méthode stop du services envoit un signal sur la socket), ce qui te permettrait de te passer de wget
24/09/2013, 19h15
tchize_

Citation:

Envoyé par Epiliptik

Oui je sais bien, le problème c'est que la fermeture avec un taskkill ou avec l'icône en haut à droite appelle la même fonction preWindowShellClose() ... Je ne trouve pas de différence entre les 2 types de fermeture dans une appli rcp.

Première chose à faire, analyse

breakpoint dans preWindowShellClose().

Ensuite, tu kille séparément avec taskill et avec la petit croix. Dans le breakpoint, tu remonte la stacktrace jusque at org.eclipse.swt.widgets.Display.windowProc(Display.java:4619)

Là, tu va trouver le message envoyé par windows à l'application. Est-ce que c'est le même ou il est différents dans les deux cas?

Si c'est le même -> Pour l'application c'est exactement la même chose, tu l'a dans l'os => boite de confirmation dans tous les cas
Si c'est différentier, faut voir un peu en aval que est l'instace de Control qui traite ce message (parce que Display dispatche aux différents Control qu'il connait) pour voir si tu n'aurais pas la possibilité de surcharger ce control, pour traiter ce message différement.
24/09/2013, 19h35
joel.drigo

Citation:

Envoyé par tchize_

Première chose à faire, analyse

breakpoint dans preWindowShellClose().

Ensuite, tu kille séparément avec taskill et avec la petit croix. Dans le breakpoint, tu remonte la stacktrace jusque at org.eclipse.swt.widgets.Display.windowProc(Display.java:4619)

Là, tu va trouver le message envoyé par windows à l'application. Est-ce que c'est le même ou il est différents dans les deux cas?

Si c'est le même -> Pour l'application c'est exactement la même chose, tu l'a dans l'os => boite de confirmation dans tous les cas
Si c'est différentier, faut voir un peu en aval que est l'instace de Control qui traite ce message (parce que Display dispatche aux différents Control qu'il connait) pour voir si tu n'aurais pas la possibilité de surcharger ce control, pour traiter ce message différement.

C'est justement ce que j'ai fait ce matin, et la seul différence que j'ai trouvée c'est celle que j'ai indiqué dans mon post (@Elliptik pourrait faire la même chose juste pour vérifier s'il a la même différence, surtout que le framework change fortement entre version d'Eclipse en plus)

Sinon, on ne peut pas envisager un truc du type de modifier un contrôle ou surcharger un code existant : aucune des instances de classes intervenant dans la stacktrace, sauf l'advisor, ne sont modifiables/remplaçables : il s'agit soit de classes natives de SWT, soit de classes privées, soit de classes internal (protégées par OSGI), soit d'instances innacessibles (private) : et c'est fait exprès, Eclipse RCP ne permet de modifier que le WorkbenchWindowAdvisor. A partir de cet advisor on peut bien sûr remplacer n'importe quelle action ou commande (par le WindowsConfigurer), donc la commande exit par exemple. Mais le bouton de fermeture de fenêtre Windows non ! A part en modifiant du code des plugins d'eclipse (y compris le code natif !)... Quand bien même on pourrait le faire, la méthode de l'advisor n'ayant pas d'argument, on pourrait pas différencier l'évenement de fermeture (on peut évidement réécrire tout le mécanisme du workbench, mais c'est pas trop le but d'utiliser un framework ;) )

C'est pour ça que je parlais d'une analyse de la stacktrace (au runtime je veux dire) pour repérer le passage dans une méthode particulière à chaque cas. C'est un peu bourrin certes (le problème de perf n'est pas trop génant vu qu'on ferme l'appli) , mais comme il n'y a pas moyen d'intercepter l'événement avant qu'il ne soit traité par le workbench, je ne vois pas d'autres solutions pour traiter la problématique de cette manière.
27/09/2013, 10h52
Epiliptik

Merci pour vos réponses, j'ai regardé la stackTrace et j’obtiens aussi un déroulement différent si la fermeture est faîte avec un taskkill ou avec l'interface donc je vais essayer de parcourir la stackTrace à chaque fois et agir en fonction du résultat!

J'ai aussi regardé les méthodes invoqués dans la stackTrace et effectivement ça me paraît être une mauvaise idée de tenter ça (voir impossible).

Si cette méthode fonctionne mon problème devrait être résolu!
27/09/2013, 11h18
tchize_

Citation:

Envoyé par Epiliptik

Si cette méthode fonctionne mon problème devrait être résolu!

Elle fonctionnera tant que tu ne changera pas de version de la librairie....

Est-ce qu'il n'y a pas quelque part dans SWT ou avec une librairie native tierce, la possibilité d'attraper directement le taskill (un peu comme on peux capter les signal sous linux), afin de marker un flag "byTaskill" statique quelque part, que tu réutiliserais au lieu de jouer avec la staktrace.
27/09/2013, 11h36
Epiliptik

J'avais déjà regardé un peu ça et je n'avais rien trouvé, on peut intercepter la fermeture de plusieurs façon mais pas le taskkill spécialement :/

Je vais quand même jeter un œil mais j'en doute, sinon ça fonctionne pour le moment mais effectivement si une maj future modifie le déroulement de la fermeture ça risque de ne plus fonctionner...
27/09/2013, 12h02
joel.drigo

Citation:

Envoyé par tchize_

Est-ce qu'il n'y a pas quelque part dans SWT ou avec une librairie native tierce, la possibilité d'attraper directement le taskill (un peu comme on peux capter les signal sous linux), afin de marker un flag "byTaskill" statique quelque part, que tu réutiliserais au lieu de jouer avec la staktrace.

Salut,

j'ai un peu cherché et je n'en ai pas trouvé. D'ailleurs il n'y a pas besoin quelle soit en SWT à priori, une API en pure java devrait suffire.

J'ai par ailleurs essayé avec un shutdownhook, mais celui-ci est invoqué après la fermeture du workbench, donc trop tard.
27/09/2013, 12h53
joel.drigo

Je viens de penser à une autre solution peut être : déterminer la liste des processes en court, et y chercher s'il n'y a pas un taskkill sur l'application elle même ?

Déjà il faudrait être sur que le taskkill est toujours "running" lorsque l'appli se ferme et également pouvoir connaitre le pid de l'appli en cours.
27/09/2013, 16h05
Epiliptik

J'avais aussi essayé avec le shutDownHook et effectivement il s’exécute après et aussi dans tous les cas donc ça ne me permet pas de différencier les cas.

Le taskkill s’exécute juste une fraction de seconde le temps d'envoyer un signal et ensuite il se termine donc inutile de checker s'il y a un processus taskkill, il n'y en aura jamais :/
27/09/2013, 16h07
joel.drigo

Citation:

Envoyé par Epiliptik

Le taskkill s’exécute juste une fraction de seconde le temps d'envoyer un signal et ensuite il se termine donc inutile de checker s'il y a un processus taskkill, il n'y en aura jamais :/

Ok. Dommage.

Il ne te reste plus qu'à bien revérifier les 2 stacktraces à chaque upgrade d'Eclipse.
27/09/2013, 18h01
tchize_

Citation:

Envoyé par joel.drigo

Ok. Dommage.

Il ne te reste plus qu'à bien revérifier les 2 stacktraces à chaque upgrade d'Eclipse.

C'est à ça que servent les unit test. Mais il va être drole à écrire le unit test qui fait un taskill sur un process tiers lancé par le unit test qui devra mettre à jour une donnée (fichier?) disant ce qu'il a repéré comme kill :mrgreen:
27/09/2013, 18h03
joel.drigo

Citation:

Envoyé par tchize_

Mais il va être drole à écrire le unit test qui fait un taskill sur un process tiers lancé par le unit test qui devra mettre à jour une donnée (fichier?) disant ce qu'il a repéré comme kill :mrgreen:

C'est clair :mouarf:
27/09/2013, 18h08
tchize_

remarque, j'ai déjà vu des unit test qui démarraient des virtualbox entières pour test 1 truc :mouarf:
27/09/2013, 18h49
joel.drigo

D'un autre coté je simplifierais les tests unitaires en considérant d'une part :

- un test unitaire avec les 2 stacktraces en entrée, qui doit renvoyer 2 résultats totalement discréminants et exclusifs pour chacune d'entre elle
- un procédure de génération de stacktrace à robotiser (le problème reste simple tant qu'on est pas en multi environnement, genre multi os, multi version d'os, multi version d'eclipse, de java etc.)

après des tests d'intégration sur déploiement peuvent suffire. il est juste indispensable d'avoir des scénarios de tests à suivre à la lettre.