Einführung

In einem Projekt mit mehreren Modulen habe ich eine War-Datei erstellt, die nicht von der Umgebung abhängt, indem ich das Webmodul und das Umgebungseinstellungsmodul getrennt habe, und versucht, sie mit Tomcat auszuführen.

Die Umgebungseinstellungen sind diesmal auf das DB-Verbindungsziel beschränkt. Mit anderen Worten, das Ziel besteht darin, dieselbe Kriegsdatei verwenden zu können, obwohl das Verbindungsziel für jeden Zweck wie Entwicklung, Verifizierungsumgebung und Produktionsumgebung bekannt sein kann.
Die Idee ist Terasoluna 3.5. Ein Entwicklungsprojekt erstellen "En-Umgebungsmodul-JAR-Datei in Kriegsdatei Es basiert auf "Wie man ohne Einbeziehung baut".
Das für die Überprüfung verwendete Projekt ist jedoch zu alt, daher habe ich mir eine Methode überlegt, die von diesem Projekt verarbeitet werden kann.
"xxx" ist die Artefakt-ID der Web-App. Da die Version 0.0.1-SNAPSHOT ist, lautet das generierte JAR auch "xxx-env-0.0.1-SNAPSHOT.jar", aber die Versionsnotation wird weggelassen.

Ziel

Trennen Sie die Umgebungseinstellungsdatei im Webmodul in ein anderes Modul
Erstellen Sie eine Einstellungsdatei für jedes DB-Verbindungsziel und erstellen Sie eine JAR-Datei mit Profil
Übergeben Sie den Pfad der Umgebungseinstellungsdatei an das Webmodul
Stellen Sie das Webmodul in Tomcat bereit

Betriebsumgebung

Windows7
Maven 3.3.9
JDK 1.7
Tomcat 7
Oracle 12.1.0.1
IDE:Eclipse 4.7.0
Tomcat ist in der Entwicklungsumgebung installiert (derselbe PC wie die IDE).

1. Trennen Sie die Umgebungseinstellungsdatei im Webmodul in ein anderes Modul

Um zu bestätigen, dass es auch dann funktioniert, wenn die Umgebungseinstellungsdatei "webapp / WEB-INF / applicationContext.xml" nach "src / main / resources / META-INF" verschoben wird, wird das Plug-in "struts-config.xml" org. Wenn ich "/ WEB-INF / applicationContext.xml", das im Parameter der Einstellungsdatei von "springframework.web.struts.ContextLoaderPlugIn" angegeben ist, in "classpath *: / META-INF / applicationContext.xml" geändert habe, funktioniert dies problemlos. tat.

Erstellen Sie daher unter dem Projekt mit mehreren Modulen ein Modul xxx-env für Umgebungseinstellungen, verschieben Sie applicationContext.xml nach "src / main / resources / META-INF" und fügen Sie xxx-env.jar zur Abhängigkeit auf der Seite des Webmoduls hinzu. Ich habe die Operation bestätigt.

Dadurch konnten wir die umgebungsabhängigen Teile der Anwendung in separate Module aufteilen.

2. Erstellen Sie eine Einstellungsdatei für jedes DB-Verbindungsziel und erstellen Sie eine JAR-Datei mit Profil

Im xxx-env-Modul haben wir drei lokale (Entwicklung) / Staging (Verifizierung) / prod (Produktion) erstellt und applicationContext.xml vorbereitet, die verschiedene DB-Verbindungsziele definieren.

local sr ・・ sr src / main / resources / META-INF / applicationContext.xml
Staging ・・ conf configs / staging / resources / META-INF / applicationContext.xml
prod ・・・ configs / prod / resources / META-INF / applicationContext.xml

Ich habe die folgenden Profile in pom.xml des xxx-env-Moduls definiert.

`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>
・ ・ ・

Wenn Sie die Profil-ID mit der Option -P angeben, wenn Sie die Paket- oder Installationsphase mit dem Befehl mvn ausführen, wird eine JAR-Datei mit der Zielressource erstellt. Bei den obigen Einstellungen ist "-P prod" xxx-env.jar für die Produktionsumgebung, "-P staging" ist xxx-env-staging.jar für die Überprüfungsumgebung und es ist nichts angegeben (Standard) für die Entwicklung. Xxx-env-dev.jar wird ausgeführt.

3. Übergeben Sie den Pfad der Umgebungseinstellungsdatei an das Webmodul

Platzieren Sie xxx-env.jar im Tomcat 7-Verzeichnis opt / environment / app, damit vom Webapps-Modul aus darauf verwiesen werden kann. Legen Sie diesmal VirtualWebappLoader in src / main / webapp / META-INF / context.xml des Webmoduls fest und fügen Sie xxx-env.jar in den Klassenpfad des Webmoduls ein.

`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>

Führen Sie das maven-war-Plugin aus, um die Datei context.xml festzulegen, die in die WAR-Datei aufgenommen werden soll.

`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. Stellen Sie das Webmodul in Tomcat bereit

Erstellen Sie eine WAR-Datei mit entfernten Einstellungen und stellen Sie sie in Tomcat bereit. Löschen Sie xxxx-env aus der Abhängigkeit und legen Sie Profile fest, damit xxxx-env beim Erstellen einer WAR nicht berücksichtigt wird.

`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>
・ ・ ・

Wie oben erwähnt, wird die Abhängigkeit nur dann aus xxx-env entfernt, wenn "P Warpack" angegeben ist. Das heißt, mvn -P warpack clean package erstellt eine WAR, die xxx-env.jar nicht enthält.

Standardmäßig ist die Abhängigkeit von xxx-env definiert. Beziehen Sie sich daher bei der Ausführung mit IDE darauf, z. B. während der Entwicklung.

Stellen Sie die erstellte WAR in den Webapps von Tomcat bereit.

Funktionsprüfung und Zusammenfassung

Als ich Tomcat startete und auf die Webanwendung zugegriffen habe, konnte ich bestätigen, dass ich auf die Datenbank für die Produktionsumgebung zugegriffen habe. Ersetzen Sie die JAR-Datei in "opt / environment / app" durch xxx-env-staging.jar für die durch "-P-Staging" erstellte Überprüfungsumgebung und starten Sie Tomcat neu, um auf die Datenbank für die Überprüfungsumgebung zuzugreifen. Bestätigt.

Auf diese Weise wird beispielsweise die WAR-Datei zur Überprüfung und Produktion verwendet, sodass die Identität des Moduls garantiert und Freigabefehler reduziert werden können.

Referenz

Terasoluna 3.5. Build Development Project Kontextspezifische Informationen in der War-Datei festlegen Apache Maven WAR Plugin [Maven] Hinzufügen von Apache Tomcat context.xml zu WAR in Maven2 Speicherort der Kontextinformationen

[JAVA] Erstellen Sie eine umgebungsunabhängige Kriegsdatei mit Mavens Profilen und dem Maven-Kriegs-Plugin