Outils pour utilisateurs

Outils du site


Panneau latéral

public:options_arguments_lancement

Options et arguments de lancement de TXM RCP en ligne de commande

-> Lancement et terminaison de TXM

Objectif

Améliorer l'architecture d'exécution de la plateforme TXM (versions RCP bureau et portail) pour mieux la contrôler.

Cela concerne le lancement et la terminaison de TXM.

Cette spécification doit recenser et homogénéiser les différents mécanismes utilisés pour influencer l'exécution de TXM :

  • arguments d'appel de TXM RCP en ligne de commande
    • arguments propres à la JVM (eg taille mémoire) et propres à TXM (eg options CQP)
  • mécanisme de préférences RCP (certaines préférences concernent la possibilité même d'exécution de TXM comme le chemin d'accès au moteur CQP)
  • fichiers TXM.ini, config.ini
  • paramètres J2EE / Tomcat de lancement de la web app TXM portal
    • paramètres Java de lancement de Tomcat (taille mémoire…)
  • paramètres de portail TXM (txmweb.pref et textometrie.properties)

Commentaire (SH) : bon c'est sûr que ces aspects portail ne correspondent pas au “TXM RCP en ligne de commande” du titre de la page.

Il y a plusieurs options utiles pour faire des tests Alpha ou alors pour mettre en place des versions Standalone de TXM :

  • désactiver les mises à jour automatique au démarrage de TXM
  • désactiver la procédure d'installation finale de TXM (dans le job de démarrage de TXM)

[SJ] Est-ce qu'il y aurait moyen d'avoir la procédure exacte, si elle existe, pour lancer TXM RCP avec tous les logs activés et ceci dès le premier lancement de TXM ? Si elle n'existe pas je pense qu'il faudrait faire des bash/batch pour cela car actuellement c'est très compliqué de debugger les parties avant initialisation complète de TXM. (Matt parlait aussi de “Run TXM in dev mode”)

Méthode

État de la plateforme

TXM RCP

Démarrage de TXM RCP :

  • un script sh ou un batch Windows
    • consulte des fichiers de configuration (TXM.ini ?)
    • lance un exécutable TXM (?)
      • SH: il semble qu'un exécutable bootstrap soit nécessaire pour lancer la JVM souhaitée. Il est difficile de trouver une définition ou spécification de ce programme, même si on peut trouver des exemples de code qui l'implémentent ou s'en rapproche.
      • SH : l'exécutable se lance avec des variables d'environnement et des options. En général les options ont priorité sur les variables d'environnement
        • variables d'environnement dont on peut avoir à tenir compte, sur une base Unix (Linux et probablement Mac OS X) :
          • PWD : le répertoire courant
          • HOME : répertoire de connexion de l'utilisateur
          • LC_MONETARY, LC_PAPER, LC_TIME, etc. : LOCALEs à utiliser pour divers traitements de chaines de caractères
          • LANG : le LOCALE par défaut (langue de l'interface)
          • PATH : chemin où seront cherchés tous les exécutables sollicités par l'exécutable au titre du système
          • LD_LIBRARY_PATH : chemin où seront cherchées toutes les librairies dynamiques chargées par l'exécutable au titre du système (en Mac OS X, c'est peut-être 'DYLD_LIBRARY_PATH', en plus ou à la place)
            • au moment de la compilation d'un exécutable, on choisit pour chaque librairie dynamique si son chemin est en dur ou s'il faudra le calculer dynamiquement (avec LD_LIBRARY_PATH)
            • la commande 'ldd' permet de lister la résolution courante des chemins des librairies dynamiques qui seront chargées par un exécutable étant données les variables d'environnement du shell qui exécute le ldd.
  • l'exécutable TXM lance une JVM avec des options et les jars de TXM
    • SH : la JVM utilise les variables d'environnement suivantes ou utilise ses options de lancement :
      • JAVA_HOME : répertoire où sera cherchée la JVM à lancer si son chemin n'est pas précisé au lancement
      • CLASSPATH : chemin où seront cherchés tous les fichiers .class, au sein de jars et zip, à charger par la JVM qui sera lancée
    • la JVM met en place l'environnement système : langue, réseau…
    • les jars mettent en place l'environnement des plugins RCP
    • les jars consultent des fichiers de configuration (preferences ?)
  • ces jars lancent la Toolbox
    • elle lance notamment libcqp et Rserve
    • et construit l'environnement de l'application (en initialisant les Préférences notamment)
  • à un moment donné on affiche la Splash
  • puis elles exécutent la boucle de la GUI
    • qui lance des threads pour réaliser les opérations demandées par l'utilisateur

Arrêt de TXM RCP :

  • un thread demande à la Toolbox de s'arrêter
    • c'est-à-dire à libcqp et Rserve de se terminer proprement
  • puis quitte la boucle de la GUI
options de ligne de commande TXM RCP

Aujourd'hui il existe déjà dans TXM RCP quelques arguments de lancement :

  • “-run” : permet de s'assurer que “TXM.exe” a bien été appelé depuis le script de lancement (sh ou bat)
  • “-noredirection” : permet d'annuler la redirection des flux std et str vers la Console de TXM
  • “-log” : permet d'activer tous les logs dès le tout début du démarrage de TXM. Cette option peut être utilisée conjointement avec les options de debug d'Eclipse :
    • “-debug” :
    • “-eclipse.consoleLog” :
    • “-eclipse.log.level=ALL” :
  • SJ: est-ce qu'il serait possible d'être plus précis sur les arguments ci-dessus liés au log ?
    • D'autre part, la syntaxe Eclipse semble utiliser des “.” pour les espaces, je propose de faire pareil avec des arguments du type : -no.redirection, -debug.TXM
    • Dans l'absolu je pense que ce serait pas mal d'indiquer la couche concernée si elle existe, ex. : tbx.debug, rcp.no.redirection ou rcp.noRedirection, etc.

Arguments propres à TXM :

  • “-run” a été mis en place depuis la version 0.7 de TXM
  • “-noredirection” a été mis en place depuis la version 0.7.6 (maj) de TXM
  • “-log” a été mis en place depuis la version 0.7.6 (maj après beta) de TXM

Avancement dans l'élaboration de la solution

Solution

État de l'art

Éléments de solution

Prototypes

Version finale

Recette

Protocole de test

Alpha

Beta

État courant

public/options_arguments_lancement.txt · Dernière modification: 2016/01/29 15:51 par slh@ens-lyon.fr