Discussion :

[w3blogfr]

Bonjour à tous, ma question n'est pas une question technique, mais plus une question de bonne pratique.
Pour mes applications Web J22 développé pour Tomcat, j'utilise des fichiers properties:

• drivers.properties pour gérer mes paramètres de connexion,etc
• log4j.properties pour les paramètres de logs

Ces fichiers se trouve dans le répertoire de mon appli dans WEB-INF\classes.

Le problème, c'est que quand dans un environnement de pré-production et production, je livre mon fichier war, qui contient mes fichiers properties.
L'administrateur du système est contraint de sauvegarde les fichier properties propre à l'environnement, d'installer le war, et ensuite de remettre les fichiers de propriété.
Certes, je pourrais envoyer directement le war avec les bons fichiers, mais je dois toujours faire une manipulation.

Existe-t-il une solution propre qui permettrais d'externaliser ses fichiers du répertoire de l'application? On pourrait ainsi mettre à jour le war, et l'application prendrait en compte automatiquement les fichiers paramètres qui se trouve dans un autre répertoire.
J'avais pensé à un valeur d'environnement, mais cela suppose de pouvoir l'enregistrer sur le serveur la première fois. Qu'en pensez-vous? Avez-vous des solutions à apporter?

[totoche]

Existe-t-il une solution propre qui permettrais d'externaliser ses fichiers du répertoire de l'application? On pourrait ainsi mettre à jour le war

Une solution peut-être de manipuler le build.xml via une tache ANT qui supprime lors de la génération du war tes fichiers.properties.

Cependant comme tu dis :

,
L'administrateur du système est contraint de sauvegarde les fichier properties propre à l'environnement, d'installer le war, et ensuite de remettre les fichiers de propriété.

Dès lors, si tu veux les externaliser, je sais que le build.xml dispose d' une balise:
<property file="monFic.properties"/>, mais je ne l'ai jamais utilisé
http://jmdoudoux.developpez.com/cour...-ant.php#ant-3
paragraphe 65.3.3. Les propriétés

[w3blogfr]

J'avais pensé à une solution similaire sur mon dernier projet.
Je disposais d'un répertoire avec mes fichiers properties correspondant à mes différents environnement : driver_dev, driver_qa,driver_prod, etc

J'avais ensuite réaliser un script ANT qui se chargait de compiler autant de war que de fichier properties. Il ne me restais plus qu'à envoyer la bonne version du war. Actuellement, c'est la solution que je trouve la mieux, mais elle est loin d'être parfaite pour diverses raisons et notamment le fait que je dois connaitre l'arborescence de chaque serveur(emplacement de tel fichiers, serveur de mail, adresse local base de donnée) pour les mettre dans mes fichiers properties et les modifications que l'administrateur du système peut apporter.

C'est dommage que l'installation Tomcat sous Linux ne conseille pas l'installation d'un répertoire pour tous les fichiers de config.
Un répertoire webapps avec les applications war qu'on met à jour
Un répertoire confapps avec les propriétés de chaque projet installé sur tomcat.

[totoche]

Salut
Je suis dans la même situation...
je refléchi à la conception d'un outil d'installation, dans lequel l'admistrateur saisirait les constantes de configuration propres à son infrastructure (cf server.xml notamment), ces constantes étant enregistrées dans un fichiers properties, puis remplaçant ensuite dans le build.xml les tokens (ex @@smtpHost@@) lors du lancement de la commande ANT run-deploy(par ex).
Voilà les grandes lignes vers lesquelles j'oriente ma démarche.

PS : Toutes suggestions sont les bienvenues

[w3blogfr]

Alors, j'ai cherché, et il semble que la solution couramment utilisé est le passable d'une variable d'environnement lors du lancement de java.

Les fichiers propriété sont chargé en conséquence. Je pense ensuite qu'il faut voir avec les équipes des serveurs pour créer un script qui permet de lancer Tomcat et Java avec cette variable en tout temps


Lire les cours et tutoriels pour apprendre la programmation Java : http://java.developpez.com/cours/

[piopium]

Tu peux également passer par le JNDI ce qui te permet d'avoir une stabilité de l'application et une forte modularité de configuration.