Configurer Tomcat pour utiliser le fichier de propriétés pour charger les informations de connexion à la base de données

Question

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?

Nous aimerions pouvoir livrer un fichier WAR et 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 que c'est une façon de faire quelque chose de façon régulière? Y a-t-il une meilleure approche que celle-ci?

Answer 1

Nous distribuons souvent des webapps en fournissant un fichier WAR, et un fichier XML de contexte, qui est placé dans votre répertoire tomcat/conf/Catalina/localhost, et peut charger la webapp à partir de n'importe quel chemin. Il existe un document de référence here. Cela présente les avantages suivants:

• paramètres de contexte peuvent être configurés ici et lus par le webapp
• DataSources peuvent être définis et configurés ici
• La guerre peut réellement vivre partout 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 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 contexte X Fichier ML pointant vers votre fichier de propriétés, lisez le paramètre dans un ServletContextListener puis lisez dans le fichier de propriétés.

Answer 2

La façon dont nous traitons ceci:

1. Demandez au client de créer un pool de connexion à l'aide d'un GlobalNamingResources nom de la ressource, nous sommes d'accord sur. Le pilote de base de données doit être dans le classpath de Tomcat.
2. Notre dossier de guerre comprend un fichier META-INF/context.xml qui a un ResourceLink un lien vers le pool de connexion configurée à l'étape 1.

Ceci est un peu plus haut travail avant que de modifier simplement le contexte. informations de connexion XML directement, mais au fil du temps, il devrait payer. Un serveur de développement serait configuré avec son GlobalNamingResources pointant vers le développement, et un point de serveur de test pour tester etc. Ensuite, le même fichier WAR peut être copié sur chaque serveur sans rien modifier.

Ceci n'utilise pas les fichiers de propriétés, mais je pense que cela permet d'atteindre 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 de guerre:

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

Answer 3

Il est une bonne pratique de stocker la configuration 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 le fragment de contexte du répertoire conf/Catalina/[hôte]. Par exemple,

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

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