introduction

Dans un projet multi-module, j'ai créé un fichier war qui ne dépend pas de l'environnement en séparant le module Web et le module de configuration d'environnement, et j'ai essayé de l'exécuter avec Tomcat.

Les paramètres d'environnement sont limités à la destination de la connexion DB cette fois. En d'autres termes, l'objectif est de pouvoir utiliser le même fichier war, bien que la destination de la connexion puisse être connue pour chaque objectif tel que le développement, l'environnement de vérification et l'environnement de production.
L'idée est Terasoluna 3.5. Construire un projet de développement "Fichier jar du module d'environnement en fichier war Il est basé sur "Comment construire sans inclure".
Cependant, le projet utilisé pour la vérification est trop hérité, j'ai donc pensé à une méthode qui peut être gérée par ce projet.
"xxx" est l'identifiant d'artefact de l'application Web. De plus, comme la version est 0.0.1-SNAPSHOT, le fichier jar généré sera également xxx-env-0.0.1-SNAPSHOT.jar, mais la notation Version est omise.

Cible

Séparez le fichier de paramètres d'environnement du module Web dans un autre module
Créez un fichier de paramètres pour chaque destination de connexion à la base de données et créez un fichier jar à l'aide du profil
Transmettez le chemin du fichier de paramètres d'environnement au module Web
Déployez le module Web sur Tomcat

Environnement d'exploitation

Windows7
Maven 3.3.9
JDK 1.7
Tomcat 7
Oracle 12.1.0.1
IDE:Eclipse 4.7.0
Tomcat est installé dans l'environnement de développement (le même PC que l'EDI).

1. Séparez le fichier de paramètres d'environnement du module Web dans un autre module

Pour confirmer que cela fonctionne même si le fichier de paramètres d'environnement webapp / WEB-INF / applicationContext.xml est déplacé vers src / main / resources / META-INF, le plug-in struts-config.xml" org. Quand j'ai changé / WEB-INF / applicationContext.xml spécifié dans le paramètre du fichier de configuration de" springframework.web.struts.ContextLoaderPlugIn "en classpath *: / META-INF / applicationContext.xml, cela fonctionne sans aucun problème. fait.

Par conséquent, sous le projet multi-module, créez un module xxx-env pour les paramètres d'environnement, déplacez applicationContext.xml vers src / main / resources / META-INF, et ajoutez xxx-env.jar à la dépendance côté module Web. J'ai confirmé l'opération.

Cela nous a permis de séparer les parties de l'application dépendant de l'environnement en modules séparés.

2. Créez un fichier de paramètres pour chaque destination de connexion à la base de données et créez un fichier jar à l'aide du profil

Dans le module xxx-env, nous avons créé trois local (développement) / staging (vérification) / prod (production) et préparé applicationContext.xml qui définit différentes destinations de connexion DB.

local ・・・・ src / main / resources / META-INF / applicationContext.xml
mise en scène ・・・ configs / staging / resources / META-INF / applicationContext.xml
prod ・・・ configs / prod / resources / META-INF / applicationContext.xml

J'ai défini les profils suivants dans pom.xml du module xxx-env.

`pom.xml(env)`


・ ・ ・
<build>
　　<finalName>${buildFinalName}</finalName>
　　<resources>
　　　　<resource>
　　　　　　<directory>${resource.directory}</directory>
　　　　</resource>
　　</resources>
</build>
<profiles>
　　<profile>
　　　　<id>local</id>
　　　　<activation>
　　　　　　<activeByDefault>true</activeByDefault>
　　　　</activation>
　　　　<properties>
　　　　　　<resource.directory>src/main/resources</resource.directory>
　　　　　　<buildFinalName>${project.artifactId}-${project.version}-dev</buildFinalName>
　　　　</properties>
　　</profile>
　　<profile>
　　　　<id>staging</id>
　　　　<properties>
　　　　　　<resource.directory>${basedir}/configs/staging/resources</resource.directory>
　　　　　　<buildFinalName>${project.artifactId}-${project.version}-staging</buildFinalName>
　　　　</properties>
　　</profile>
　　<profile>
　　　　<id>prod</id>
　　　　<properties>
　　　　　　<resource.directory>${basedir}/configs/prod/resources</resource.directory>
　　　　　　<buildFinalName>${project.artifactId}-${project.version}</buildFinalName>
　　　　</properties>
    </profile>
</profiles>
・ ・ ・

Si vous spécifiez l'ID de profil avec l'option -P lors de l'exécution de la phase de package ou d'installation avec la commande mvn, un fichier jar sera créé avec la ressource cible. Dans le cas des paramètres ci-dessus, -P prod est xxx-env.jar pour l'environnement de production, -P staging est xxx-env-staging.jar pour l'environnement de vérification et rien n'est spécifié (par défaut) pour le développement. Xxx-env-dev.jar est exécuté.

3. Transmettez le chemin du fichier de paramètres d'environnement au module Web

Placez xxx-env.jar dans le répertoire Tomcat 7 ʻopt / environment / app` afin qu'il puisse être référencé à partir du module webapps. Cette fois, définissez VirtualWebappLoader dans src / main / webapp / META-INF / context.xml du module Web et incluez xxx-env.jar dans le Classpath du module Web.

`src/main/webapp/META-INF/context.xml`


<?xml version='1.0' encoding='utf-8'?>
<Context>
  <Loader className="org.apache.catalina.loader.VirtualWebappLoader" virtualClasspath="/opt/environment/logtime/prod/*.jar"/>
  <JarScanner scanAllDirectories="true"/>
</Context>

Exécutez maven-war-plugin pour définir context.xml à inclure dans le fichier WAR.

`pom.xml(web)`


・ ・ ・
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <version>2.5</version>
  <configuration>
    <containerConfigXML>src/main/webapp/META-INF/context.xml</containerConfigXML>
  </configuration>
</plugin>
・ ・ ・

4. Déployez le module Web sur Tomcat

Créez un fichier WAR avec les préférences supprimées et déployez-le sur Tomcat. Supprimez xxxx-env de la dépendance et définissez les profils afin que xxxx-env ne soit pas inclus lors de la création d'un WAR.

`pom.xml(Web)`


・ ・ ・
<profiles>
  <profile>
    <id>local</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <dependencies>
      <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>xxxx-env</artifactId>
	<version>0.0.1-SNAPSHOT</version>
      </dependency>
    </dependencies>
  </profile>
  <profile>
    <id>warpack</id>
  </profile>
</profiles>
・ ・ ・

Comme mentionné ci-dessus, la dépendance est supprimée de xxx-env uniquement lorsque «-P warpack» est spécifié. Autrement dit, mvn -P warpack clean package crée un WAR qui n'inclut pas xxx-env.jar.

Par défaut, la dépendance sur xxx-env est définie, alors faites-y référence lors de l'exécution avec IDE, par exemple pendant le développement.

Déployez le WAR créé sur les applications Web de Tomcat.

Contrôle de fonctionnement et résumé

Lorsque j'ai démarré Tomcat et accédé à l'application Web, j'ai pu confirmer que j'accédais à la base de données pour l'environnement de production. ʻRemplacez le fichier jar dans opt / environment / apppar xxx-env-staging.jar pour l'environnement de vérification créé par-P staging`, redémarrez Tomcat, et cette fois, vous pouvez accéder à la base de données pour l'environnement de vérification. confirmé.

En faisant cela, par exemple, le fichier WAR est utilisé pour la vérification et la production, ainsi l'identité du module peut être garantie et les erreurs de version peuvent être réduites.

référence

Terasoluna 3.5. Projet de développement de build Définissez les informations contextuelles dans le fichier War Apache Maven WAR Plugin [Maven] Comment ajouter Apache Tomcat context.xml à WAR dans Maven2 Emplacement des informations de contexte

[JAVA] Créez un fichier war indépendant de l'environnement en utilisant les profils de Maven et maven-war-plugin