web-dev-qa-db-fra.com

Configurer Tomcat pour utiliser le fichier de propriétés pour charger les informations de connexion DB

Quelles sont les pratiques acceptées pour créer un déploiement Tomcat qui lit les paramètres de configuration à partir d'un fichier de propriétés?

Ce serait bien de pouvoir livrer un fichier WAR et de spécifier que le client n'a qu'à créer ou éditer un fichier de propriétés dans un répertoire spécifique. Est-ce une façon quelque peu régulière de faire les choses? Existe-t-il une meilleure approche que celle-ci?

javadeploymenttomcatproperties
31
jW.

Nous distribuons souvent des applications Web en fournissant un fichier WAR et un fichier XML de contexte, qui sont placés dans votre Tomcat/conf/Catalina/localhost et peut charger la webapp depuis n'importe quel chemin. Il existe un document de référence ici . Cela offre les avantages suivants:

  • Les paramètres de contexte peuvent être configurés ici et lus par la webapp
  • Les DataSources peuvent être définies et configurées ici
  • Le WAR peut réellement vivre n'importe où sur le système de fichiers, ce qui signifie que si Tomcat est mis à niveau, seul ce fichier de configuration unique doit être déplacé vers la nouvelle installation de Tomcat, l'application Web et tous les autres fichiers peuvent rester où ils sont

Si vous voulez vraiment un fichier de propriétés, vous pouvez définir un paramètre dans le fichier XML de contexte pointant vers votre fichier de propriétés, lire le paramètre dans un ServletContextListener puis lire dans le fichier de propriétés.

14
Adam Batkin

La façon dont nous gérons cela:

  1. Demandez au client de créer un pool de connexions dans GlobalNamingResources en utilisant un nom de ressource sur lequel nous nous entendons. Le pilote de base de données doit se trouver dans le chemin d'accès aux classes de Tomcat.
  2. Notre fichier war comprend un fichier META-INF/context.xml qui a une liaison ResourceLink avec le pool de connexions configuré à l'étape 1.

C'est un peu plus de travail initial que de simplement modifier directement les informations de connexion context.xml, mais avec le temps, cela devrait porter ses fruits. Un serveur de développement serait configuré avec ses GlobalNamingResources pointant vers le développement, et un serveur de test pointant pour tester etc. Ensuite, le même fichier WAR peut être copié sur chaque serveur sans rien éditer.

Ce n'est pas en utilisant des fichiers de propriétés, mais je pense que cela atteint le même objectif. Permettre à un utilisateur/client de configurer les informations de connexion à la base de données.

Exemple de GlobalNamingResource:

<Resource name="jdbc/dbconnection" auth="Container"
type="javax.sql.DataSource" driverClassName="Oracle.jdbc.driver.OracleDriver"
url="jdbc:Oracle:thin:@127.0.0.1:1546:SID"
username="scott" password="tiger" maxActive="8" maxIdle="4"
validationQuery="select 1 from dual"
testOnBorrow="true"/>

Exemple de context.xml dans le fichier war:

<Context path="/MyWebApp" docBase="MyWebApp" debug="5" reloadable="true">
    <ResourceLink name="jdbc/dbconnection" global="jdbc/dbconnection" 
          type="javax.sql.DataSource"/>
</Context>
9
Steve K

Il est recommandé de stocker la configuration hors de la zone de guerre. Dans notre WAR, nous avons un emplacement par défaut pour rechercher le fichier de propriétés. Si la valeur par défaut ne fonctionne pas, vous pouvez spécifier l'emplacement via un paramètre JVM ou un paramètre de contexte défini dans un fragment de contexte dans le répertoire conf/Catalina/[Host]. Par exemple,

<Context docBase="/server/app.war"
    swallowOutput="true" unpackWAR="false" useNaming="false">

    <Parameter name="config-file" value="/config/db.properties" override="true" />
</Context>
8
ZZ Coder