Fonctionnement de l'option app.name
Bonjour, Dans Applicationconfig, il y a une option speciale qui sert a prefixer les options par un prefix dans le cas ou plusieurs applications tourne dans un même conteneur. Exemple, dans tomcat, avec coser et wao -Dwao.config.file=xxx.properties -Dcoser.config.file=zzz.properties Coser utilisant un prefix "coser." il ne va lire que les options qui le concerne. Idem pour wao. Seulement, il y a plusieurs problèmes a ce fonctionnement: - les options par defaut sont positionnées sans le prefix, et le prefix est renseignés apres l'instanciation (ano : http://nuiton.org/issues/1862) - le code test pour 2 ou 3 options seulement ce mécanisme config.file et encoding (c'est donc limité en nombre d'option) - Vu le code ca n'a pas l'air très souple (codé à coup de if/else pour les 2/3 options, et si on voulait ajouter d'autre options ? http://nuiton.org/projects/nuiton-utils/repository/revisions/2251/entry/trun... Avez vous des idées pour améliorer ce fonctionnement ? -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le Fri, 23 Dec 2011 16:55:55 +0100, Eric Chatellier <chatellier@codelutin.com> a écrit :
Bonjour,
Dans Applicationconfig, il y a une option speciale qui sert a prefixer les options par un prefix dans le cas ou plusieurs applications tourne dans un même conteneur.
Exemple, dans tomcat, avec coser et wao -Dwao.config.file=xxx.properties -Dcoser.config.file=zzz.properties
Coser utilisant un prefix "coser." il ne va lire que les options qui le concerne. Idem pour wao.
Seulement, il y a plusieurs problèmes a ce fonctionnement: - les options par defaut sont positionnées sans le prefix, et le prefix est renseignés apres l'instanciation (ano : http://nuiton.org/issues/1862) - le code test pour 2 ou 3 options seulement ce mécanisme config.file et encoding (c'est donc limité en nombre d'option) - Vu le code ca n'a pas l'air très souple (codé à coup de if/else pour les 2/3 options, et si on voulait ajouter d'autre options ?
http://nuiton.org/projects/nuiton-utils/repository/revisions/2251/entry/trun...
Avez vous des idées pour améliorer ce fonctionnement ?
Un peu chaud de se remettre dans le code. Je me demande si l'encoding devrait avoir le prefixe comme pour le fileName. Finalement l'encoding sera définis dans l'appli, alors que le nom du fichier peut etre externalisé et donc en paramètre du serveur. Ca reste discutable, mais dans ce cas comme le suggère Eric pourquoi ne pas préfixer toutes les options ? C'est un peu le mic-mac entre le configPath, le configFileName, le prefixe du appName et l'encoding (tout ca dans l'optique de parse du fichier). La comme ca j'ai pas de solution miracle, mais la nuit porte conseil ;)
Le 26/12/2011 00:19, fdesbois a écrit :
Un peu chaud de se remettre dans le code. Je me demande si l'encoding devrait avoir le prefixe comme pour le fileName. Finalement l'encoding sera définis dans l'appli, alors que le nom du fichier peut etre externalisé et donc en paramètre du serveur. Ca reste discutable, mais dans ce cas comme le suggère Eric pourquoi ne pas préfixer toutes les options ? En fait non, le prefix sert a diférrencié les options communes a plusieurs appli car c'est application config lui même qui les définies.
-- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
On Fri, 23 Dec 2011 16:55:55 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Bonjour,
Dans Applicationconfig, il y a une option speciale qui sert a prefixer les options par un prefix dans le cas ou plusieurs applications tourne dans un même conteneur.
Exemple, dans tomcat, avec coser et wao -Dwao.config.file=xxx.properties -Dcoser.config.file=zzz.properties
Coser utilisant un prefix "coser." il ne va lire que les options qui le concerne. Idem pour wao.
Je ne sais pas si j'ai tout compris, mais je vais essayer une reponse :) Ce que je verrais est une methode sur AppConfig qui permette d'avoir une sous config en fonction d'un prefix. AppConfig conf2 = config.getConfig("monprefix."); on peut faire le parse() avant ou apres l'appel de getConfig (pour gere comme dans l'exemple de pouvoir prefixer aussi le fichier de config a lire. Lorsqu'on utilise conf2 pour recuperer une option:: conf2.getOption("toto") En fait il recherche automatiquement "monprefix.toto" s'il ne le trouve pas il recherche "toto" (pour toujours offrir la possibilite d'avoir des options par defaut. si on melange la conf de wao et coser on pourrait avoir un fichier de la forme: topia.driver=psql wao.topia.db=waodb coser.topia.db=coserdb Donc - config.getOption("topia.db") -> null - config.getConfig("wao.").getOption("topia.db") -> waodb - config.getConfig("coser.").getOption("topia.db") -> coserdb Et de la meme facon, si on fait un setOption le prefix est automatiquement ajouter donc: config.getConfig("wao.").getOption("topia.driver") -> psql config.getConfig("wao.").setOption("topia.driver", "h2") le fichier de config si on le sauve devient: topia.driver=psql wao.topia.driver=h2 wao.topia.db=waodb coser.topia.db=coserdb Ce mecanisme serait un vrai plus, on en a besoin par exemple dans wikitty, car on peut avoir plusieurs configurations concurrentes: - WikittyService standard - WikittyService fallback - WikittyService transaction Et on a besoin des trois dans le meme fichier de config. Lorsqu'on veut la config pour creer une nouvelle transaction il suffirait alors de passer comme AppConfig: config.getConfig("Wikitty.tx.") Qui lirait l'option wikitty.tx.wikkity.WikittyService.components au lieu de simplement wikkity.WikittyService.components Par contre pour d'autres options ou la valeur par defaut suffit il suffit de ne pas la redefinir avec le prefix pour que celle par defaut soit prise. Je ne pense pas que ce soit tres compliqué a developper. Il suffit de faire une sous classe et surcharger le getOption/setOption que tout le reste utilise (mais je dis ca de memoire :)) ps: je m'interroge s'il faut que l'utilisateur mette le "." a la fin du prefix ou si on l'ajoute automatiquement ? Je dirais, il faut qu'il le mette car nous on a pris le parti de mettre des '.' mais d'autre pourrait vouloir mettre des '_' ou des majuscules (a la java) pour separer les mots de la cle. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
participants (3)
-
Benjamin POUSSIN -
Eric Chatellier -
fdesbois