Surcharge de la méthode parse() de ApplicationConfig
Bonjour, Il faudrait trouver un mécanisme pour pourvoir utiliser application config dans le cas des test, sans qu'il aille lire le fichier dans /etc/. Je pensais à diviser la méthode parse() en plusieurs petite méthode, pour par exemple pouvoir surcharger la méthode parse qui charge le fichier dans /etc. -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Eric Chatellier a écrit :
Bonjour,
Il faudrait trouver un mécanisme pour pourvoir utiliser application config dans le cas des test, sans qu'il aille lire le fichier dans /etc/.
Je pensais à diviser la méthode parse() en plusieurs petite méthode, pour par exemple pouvoir surcharger la méthode parse qui charge le fichier dans /etc.
je pense que ApplicationConfig devrait rechercher les options de configuration dans le classpath *avant* /etc/ , ainsi lors des tests, ton fichier de config de test serait lu avant celui de /etc/.
Le 25/02/2010 11:13, Stephane CHORLET a écrit :
je pense que ApplicationConfig devrait rechercher les options de configuration dans le classpath *avant* /etc/ , ainsi lors des tests, ton fichier de config de test serait lu avant celui de /etc/. C'est le cas, le fichier du classpath est lu avant celui de /etc. Mais celui de /etc écrase celui du classpath.
-- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Eric Chatellier a écrit :
Le 25/02/2010 11:13, Stephane CHORLET a écrit :
je pense que ApplicationConfig devrait rechercher les options de configuration dans le classpath *avant* /etc/ , ainsi lors des tests, ton fichier de config de test serait lu avant celui de /etc/. C'est le cas, le fichier du classpath est lu avant celui de /etc. Mais celui de /etc écrase celui du classpath.
donc je reformule, je pense les options du classpath devraient avoir une priorité supérieure à celles de /etc/.
Le 25/02/2010 11:30, Stephane CHORLET a écrit :
donc je reformule, je pense les options du classpath devraient avoir une priorité supérieure à celles de /etc/.
Mais le fichier du classpath existe tjs. Donc la surcharge du fichier dans /etc n'a pas d'effet. En test comme en exécution normale. -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Le 25.02.2010 11:30, Stephane CHORLET a écrit :
Eric Chatellier a écrit :
Le 25/02/2010 11:13, Stephane CHORLET a écrit :
je pense que ApplicationConfig devrait rechercher les options de configuration dans le classpath *avant* /etc/ , ainsi lors des tests, ton fichier de config de test serait lu avant celui de /etc/. C'est le cas, le fichier du classpath est lu avant celui de /etc. Mais celui de /etc écrase celui du classpath.
donc je reformule, je pense les options du classpath devraient avoir une priorité supérieure à celles de /etc/.
Euh, non, au contraire je dirais ! /etc/ sert à surcharger la conf par défaut... Je n'ai pas de bonne solution pour toi Éric. Pkoi pas découper en 2 oui, mais prends le cas d'un projet utilisant Topia, il va toujours aller lire le fichier dans /etc, non ? Arnaud. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
Le 26.02.2010 10:32, Arnaud Thimel a écrit :
Le 25.02.2010 11:30, Stephane CHORLET a écrit :
Eric Chatellier a écrit :
Le 25/02/2010 11:13, Stephane CHORLET a écrit :
je pense que ApplicationConfig devrait rechercher les options de configuration dans le classpath *avant* /etc/ , ainsi lors des tests, ton fichier de config de test serait lu avant celui de /etc/.
[...] Je n'ai pas de bonne solution pour toi Éric.
Peut-être simplement désactiver la lecture dans /etc si un variable d'env NO_ETC_CONFIG est présente ? Arnaud. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
Pkoi pas découper en 2 oui, mais prends le cas d'un projet utilisant Topia, il va toujours aller lire le fichier dans /etc, non ?
Oui, c'est juste pour qu'on ai la possibilité de ne pas le faire dans certains cas (pour isoler les tests dans le cas présent). -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Arnaud Thimel a écrit :
Euh, non, au contraire je dirais ! /etc/ sert à surcharger la conf par défaut...
Justement, je pense que /etc/ devrait être la conf par défaut et que tout ce qui est dans le classpath ou variable d'environnement ou fichier dans le home de l'utilisateur devrait avoir une priorité supérieure à /etc/
Le 26.02.2010 10:46, Stephane CHORLET a écrit :
Arnaud Thimel a écrit :
Euh, non, au contraire je dirais ! /etc/ sert à surcharger la conf par défaut...
Justement, je pense que /etc/ devrait être la conf par défaut et que tout ce qui est dans le classpath ou variable d'environnement ou fichier dans le home de l'utilisateur devrait avoir une priorité supérieure à /etc/
J'entends bien c'que tu dis et pourtant, je continues de penser le contraire. Je prends un exemple : classpath:mail.properties ========================= smtp.host: smtp.free.fr /etc/mail.properties ==================== smtp.host: 10.50.3.2 Avec ce que tu proposes, lors d'un déploiement sur le serveur, la valeur qui sera prise est celle dans le classpath. Or au build de mon JAR, je ne peux pas anticiper l'environnement de runtime de mon appli et donc l'adresse du smtp à utiliser ? Ou je me vois mal forcer les gens qui veulent déployer notre appli à ajouter une entrée "10.50.3.2 smtp.free.fr" dans leur /etc/hosts pour pouvoir envoyer des mails ?? Arnaud. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
Arnaud Thimel a écrit :
Le 26.02.2010 10:46, Stephane CHORLET a écrit :
Arnaud Thimel a écrit :
Euh, non, au contraire je dirais ! /etc/ sert à surcharger la conf par défaut...
Justement, je pense que /etc/ devrait être la conf par défaut et que tout ce qui est dans le classpath ou variable d'environnement ou fichier dans le home de l'utilisateur devrait avoir une priorité supérieure à /etc/
J'entends bien c'que tu dis et pourtant, je continues de penser le contraire.
Je prends un exemple :
classpath:mail.properties =========================
smtp.host: smtp.free.fr
/etc/mail.properties ====================
smtp.host: 10.50.3.2
Avec ce que tu proposes, lors d'un déploiement sur le serveur, la valeur qui sera prise est celle dans le classpath. Or au build de mon JAR, je ne peux pas anticiper l'environnement de runtime de mon appli et donc l'adresse du smtp à utiliser ? Ou je me vois mal forcer les gens qui veulent déployer notre appli à ajouter une entrée "10.50.3.2 smtp.free.fr" dans leur /etc/hosts pour pouvoir envoyer des mails ??
Arnaud.
Au build du jar, tu met une conf par défaut, genre une base h2 ou derby. Lors d'une installation, une pratique courante est de dezipper le jar ou le war et de modifier les fichiers de conf présents et de repackager le tout. Je comprend bien que donner une priorité supérieure à /etc/ représente une facilité, mais cela introduit un comportement inhabituel. Ca pose des problèmes pour les tests (le problème de eric) et ça en posera si tu souhaites installer 2 instances de ton application sur un même serveur.
Le 26/02/2010 11:35, Stephane CHORLET a écrit :
Arnaud Thimel a écrit :
Le 26.02.2010 10:46, Stephane CHORLET a écrit :
Arnaud Thimel a écrit :
Euh, non, au contraire je dirais ! /etc/ sert à surcharger la conf par défaut...
Justement, je pense que /etc/ devrait être la conf par défaut et que tout ce qui est dans le classpath ou variable d'environnement ou fichier dans le home de l'utilisateur devrait avoir une priorité supérieure à /etc/
J'entends bien c'que tu dis et pourtant, je continues de penser le contraire.
Je prends un exemple :
classpath:mail.properties =========================
smtp.host: smtp.free.fr
/etc/mail.properties ====================
smtp.host: 10.50.3.2
Avec ce que tu proposes, lors d'un déploiement sur le serveur, la valeur qui sera prise est celle dans le classpath. Or au build de mon JAR, je ne peux pas anticiper l'environnement de runtime de mon appli et donc l'adresse du smtp à utiliser ? Ou je me vois mal forcer les gens qui veulent déployer notre appli à ajouter une entrée "10.50.3.2 smtp.free.fr" dans leur /etc/hosts pour pouvoir envoyer des mails ??
Arnaud.
Au build du jar, tu met une conf par défaut, genre une base h2 ou derby. Lors d'une installation, une pratique courante est de dezipper le jar ou le war et de modifier les fichiers de conf présents et de repackager le tout. Je me vois mal, à chaque fois que je déploie quelque chose, modifier le fichier de properties du war/jar, heureusement qu'il prend celui dans /etc ! Je comprend bien que donner une priorité supérieure à /etc/ représente une facilité, mais cela introduit un comportement inhabituel.
Ca pose des problèmes pour les tests (le problème de eric) et ça en posera si tu souhaites installer 2 instances de ton application sur un même serveur. Non, car tes 2 instances n'auront pas le même nom ;) Sur orion (qui n'est peut être pas un bon exemple ?) j'ai plusieurs instances et dans /etc j'ai :
orion-bms-buy.properties orion-bms.properties orion-glon.properties orion.properties Je pense que la variable d'environnement est une bonne idée pour palier au problème. Sylvain
letellier a écrit :
Le 26/02/2010 11:35, Stephane CHORLET a écrit :
Arnaud Thimel a écrit :
Le 26.02.2010 10:46, Stephane CHORLET a écrit :
Arnaud Thimel a écrit :
Euh, non, au contraire je dirais ! /etc/ sert à surcharger la conf par défaut...
Justement, je pense que /etc/ devrait être la conf par défaut et que tout ce qui est dans le classpath ou variable d'environnement ou fichier dans le home de l'utilisateur devrait avoir une priorité supérieure à /etc/
J'entends bien c'que tu dis et pourtant, je continues de penser le contraire.
Je prends un exemple :
classpath:mail.properties =========================
smtp.host: smtp.free.fr
/etc/mail.properties ====================
smtp.host: 10.50.3.2
Avec ce que tu proposes, lors d'un déploiement sur le serveur, la valeur qui sera prise est celle dans le classpath. Or au build de mon JAR, je ne peux pas anticiper l'environnement de runtime de mon appli et donc l'adresse du smtp à utiliser ? Ou je me vois mal forcer les gens qui veulent déployer notre appli à ajouter une entrée "10.50.3.2 smtp.free.fr" dans leur /etc/hosts pour pouvoir envoyer des mails ??
Arnaud.
Au build du jar, tu met une conf par défaut, genre une base h2 ou derby. Lors d'une installation, une pratique courante est de dezipper le jar ou le war et de modifier les fichiers de conf présents et de repackager le tout. Je me vois mal, à chaque fois que je déploie quelque chose, modifier le fichier de properties du war/jar, heureusement qu'il prend celui dans /etc ! Je comprend bien que donner une priorité supérieure à /etc/ représente une facilité, mais cela introduit un comportement inhabituel.
Ca pose des problèmes pour les tests (le problème de eric) et ça en posera si tu souhaites installer 2 instances de ton application sur un même serveur. Non, car tes 2 instances n'auront pas le même nom ;) Sur orion (qui n'est peut être pas un bon exemple ?) j'ai plusieurs instances et dans /etc j'ai :
orion-bms-buy.properties orion-bms.properties orion-glon.properties orion.properties
Je pense que la variable d'environnement est une bonne idée pour palier au problème.
Sylvain
Bah moi je laisse tomber. Je pense que ce comportement est bug qui constitue une fonctionnalité de ApplicationConfig, soit.
Le 26.02.2010 11:35, Stephane CHORLET a écrit :
Au build du jar, tu met une conf par défaut, genre une base h2 ou derby. Lors d'une installation, une pratique courante est de dezipper le jar ou le war et de modifier les fichiers de conf présents et de repackager le tout.
Pratique courante, oui. Mais pour moi c'est une mauvaise pratique.
Je comprend bien que donner une priorité supérieure à /etc/ représente une facilité, mais cela introduit un comportement inhabituel.
Disons que pour moi la conf d'une appli est relative à une machine, et il est donc logique que cette conf soit séparée du binaire. Et je ne pense pas que nous soyons les seuls à faire ça. Regardes ce que tu installes sur ton système (exemple un serveur FTP), si télécharges/installes le binaire puis tu modifies sa conf dans /etc. Quand tu mets à jour ton binaire, ta conf ne saute pas. Pourquoi ne pas faire pareil avec nos applis ?
Ca pose des problèmes pour les tests (le problème de eric) et ça en posera si tu souhaites installer 2 instances de ton application sur un même serveur.
C'est vrai. Au même titre que quand je veux installer 2 serveurs FTP. Dans ce cas particulier, tu adaptes ta conf... Arnaud. PS: Désolé d'avoir ""relancer"" le débat alors que tu as dit "Bah moi je laisse tomber". Mais je n'avais pas eu le temps de m'exprimer entre tes 2 derniers mails. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
On Fri, 26 Feb 2010 14:25:15 +0100 Arnaud Thimel <thimel@codelutin.com> wrote: Juste pour dire que je suis d'accord avec Arnaud :D pour ce qui est du probleme de multiple instance, il suffit de surcharge la valeur de 'config.file' sur la ligne de commande de lancement de l'application ou dans les properties de la JVM ou dans les variables d'environnement. Et ca devrait rouler, car ces 3 choses la sont evaluer avant de rechercher le fichier de config et donc le nom de celui-ci peut-etre changer par exemple pour 2 instances ou pour les besoins des tests. Donc a moins que vous ayez beaucoup modifier le code (j'ai pas update avant de verifier), c deja dans ApplicationConfig.
Le 26.02.2010 11:35, Stephane CHORLET a écrit :
Au build du jar, tu met une conf par défaut, genre une base h2 ou derby. Lors d'une installation, une pratique courante est de dezipper le jar ou le war et de modifier les fichiers de conf présents et de repackager le tout.
Pratique courante, oui. Mais pour moi c'est une mauvaise pratique.
Je comprend bien que donner une priorité supérieure à /etc/ représente une facilité, mais cela introduit un comportement inhabituel.
Disons que pour moi la conf d'une appli est relative à une machine, et il est donc logique que cette conf soit séparée du binaire.
Et je ne pense pas que nous soyons les seuls à faire ça. Regardes ce que tu installes sur ton système (exemple un serveur FTP), si télécharges/installes le binaire puis tu modifies sa conf dans /etc. Quand tu mets à jour ton binaire, ta conf ne saute pas. Pourquoi ne pas faire pareil avec nos applis ?
Ca pose des problèmes pour les tests (le problème de eric) et ça en posera si tu souhaites installer 2 instances de ton application sur un même serveur.
C'est vrai. Au même titre que quand je veux installer 2 serveurs FTP. Dans ce cas particulier, tu adaptes ta conf...
Arnaud.
PS: Désolé d'avoir ""relancer"" le débat alors que tu as dit "Bah moi je laisse tomber". Mais je n'avais pas eu le temps de m'exprimer entre tes 2 derniers mails.
-- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
_______________________________________________ Nuiton-utils-devel mailing list Nuiton-utils-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/nuiton-utils-devel
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Eric Chatellier a écrit :
Bonjour,
Il faudrait trouver un mécanisme pour pourvoir utiliser application config dans le cas des test, sans qu'il aille lire le fichier dans /etc/.
Je pensais à diviser la méthode parse() en plusieurs petite méthode, pour par exemple pouvoir surcharger la méthode parse qui charge le fichier dans /etc.
du coup, t'as trouvé quoi comme solution eric ?
participants (5)
-
Arnaud Thimel -
Benjamin POUSSIN -
Eric Chatellier -
letellier -
Stephane CHORLET