nutools/doc/ulib_webobjects.md

# ulib/webobjects

## `compute_webobjects_prefixes`
## `recompute_webobjects_prefixes`
## `get_NEXT_ROOT_prefix`
## `get_WOROOT_prefix`
## `get_LOCALROOT_prefix`
## `get_SYSTEMFRAMEWORKS_prefix`
## `get_WOEXTENSIONS_prefix`
## `get_WOFRAMEWORKS_prefix`
## `get_WOAPPLICATIONS_prefix`
## `get_WOCONFIGURATION_prefix`
## `get_WOAUTOSTART_prefix`
## `get_WOLOGS_prefix`
## `get_WOVERSION_prefix`
## `is_wobundle`
~~~
Tester si $1 a un nom de bundle valide, c'est à dire avec l'extension .woa
ou .framework
~~~
## `is_woappdir`
~~~
Tester si $1 est un répertoire d'application webobjects. Le test est
effectué sur le contenu du bundle, pas sur le nom (utiliser is_wobundle()
pour cela)
~~~
## `is_wofwkdir`
~~~
Tester si $1 est un répertoire de framework webobjects. Le test est
effectué sur le contenu du bundle, pas sur le nom (utiliser is_wobundle()
pour cela)
~~~
## `get_app_winclspth`
~~~
calculer la valeur de Contents/Windows/CLSSPATH.txt pour l'application $1
~~~
## `get_infofile`
~~~
Obtenir le chemin vers le fichier Info.plist dans le répertoire de
resource du bundle $1
~~~
## `read_infofile`
~~~
Lire la version et le numéro de release dans le fichier $1 (chemin vers
Info.plist) et les placer dans les variables $2(=version) et $3(=release)
Retourner 1 si un erreur s'est produite, par exemple si le fichier $1
n'existe pas ou n'est pas accessible en lecture
~~~
## `write_infofile`
~~~
Ecrire $2 (la version) et $3 (le numéro de release) dans le fichier $1
(chemin vers Info.plist)
Retourner 1 si un erreur s'est produite, par exemple si le fichier $1
n'existe pas
~~~
## `get_jawotoolsfile`
~~~
Obtenir le chemin vers le fichier jawotools.properties dans le bundle $1
~~~
## `read_jawotoolsfile`
~~~
lire le fichier de propriété $1 et placer les valeurs dans les variables
$2(=version), $3(=releaseDate), $4(=description)
~~~
## `save_jawotoolsfile`
~~~
écrire le fichier de propriété $1 avec les valeurs version ($2),
releaseDate ($3) et description ($4)
~~~
## `get_versionfile`
~~~
Obtenir le chemin vers le fichier VERSION.txt dans le répertoire de
resource du bundle $1
~~~
## `get_configfile`
~~~
obtenir le chemin vers le fichier de configuration du répertoire de
resource du bundle
$1=bundle ou resdir (appdir/Contents/Resources ou fwkdir/Resources)
~~~
## `searchreplace_classpath`
~~~
Dans les fichiers classpath de l'application $1, remplacer $2 par $3. Si
$3 est vide, la ligne est supprimée
~~~
## `dump_jars`
~~~
Afficher les jars des frameworks utilisés par l'application $1
~~~
## `dump_frameworks`
~~~
Afficher les frameworks utilisés par l'application $1
~~~
## `remove_framework`
~~~
supprimer le framework $2 (nom de base) des fichiers de classpath du
bundle d'application $1
~~~
## `add_framework`
~~~
s'il n'y existe pas déjà, ajouter le framework $2 (nom de base ou chemin
absolu) aux fichiers de classpath du bundle d'application $1
~~~
## `fix_jars_case`
~~~
Vérifier que la casse des jars de tous les frameworks utilisés par
l'application $1 est conforme au système de fichier
~~~
## `verifix_bundle`
~~~
vérifier et corriger le bundle $1. Pour une application, on vérifie que le
script est exécutable. Pour un framework, on vérifie que le framework est
conforme au modèle des framework générés par WebObjects.
~~~
## `compute_fapps`
~~~
Placer dans le tableau $1(=fappnames) la liste des noms de bundle
d'applications qui dépendent du framework $2
Cette opération est faite à partir des informations sur le système de
fichier. Elle ne peut donc concerner qu'une installation locale.
~~~
## `woraurl`
~~~
Faire une requête avec la méthode $1 sur l'url $2 avec le payload $3 (par
exemple pour la méthode POST). la réponse est disponible dans le fichier
$WORAURL_DATA, $4(=http_code) contient le code de réponse.
Retourner 0 en cas de succès, ou une valeur différente de zéro si un
erreur se produit (typiquement, 3 pour une erreur du serveur, 1 pour une
réponse applicative, comme par exemple si l'application n'existe pas)
Les codes de réponse 2xx et 417 sont des succès
Les autres codes (à priori 4xx ou 5xx) sont des erreurs
note: le code 417 est utilisé par le moniteur pour répondre "Non", par
opposition à 200 utilisé pour répondre "OUI"
~~~
## `wogeturl`
## `splitins`
~~~
Analyser le nom $1, qui peut être de forme '', 'Name.woa',
'Name.framework', 'App' ou 'Instance-N' (où N est un nombre), et
initialiser les variables $2(=type) et $3(=name)
Si $1=="", type=all et name=""
Si $1==Name.woa, type=woa et name=Name.woa
Si $1==Name.framework, type=fwk et name=Name.framework
Si $1==App, type=app et name=App
si $1==App-N, type=ins et name=App-N
~~~
## `create_wodirs_maybe`
## `check_autostart`
~~~
vérifier la présence du fichier $WOAUTOSTART. Si ce n'est pas le cas, le
créer avec le contenu du tableau $1
~~~
## `get_autostart_order`
~~~
Initialiser le tableau $1 avec la liste donnée dans le fichier
$WOAUTOSTART
~~~
## `apply_autostart_order`
~~~
Réordonner les valeurs $3..* selon la liste donnée dans le tableau $2,
puis placer le résultat dans le tableau $1. $2 doit être construit avec
get_autostart_order(). Si $2 n'est pas spécifié, la liste est construite
localement.
Si le tableau contient des lignes de délai @N, replacer les délais après
les applications appropriées
~~~
## `wotaskd_stop`
## `wotaskd_start`
## `javamonitor_stop`
## `womonitor_stop`
## `javamonitor_start`
## `womonitor_start`
## `woservices_stop`
## `woservices_start`

-*- coding: utf-8 mode: markdown -*- vim:sw=4:sts=4:et:ai:si:sta:fenc=utf-8:noeol:binary