Once and for all deployment project: Load environment variables via tomcat

I. DescriptionXxx.properties is often used as a configuration file for some parameters in the project, and these parameters are loaded into the environment variable when the tomcat is started for subsequent code calls. Because of the particularity of the project, it is necessary to deploy multiple copies of the same war, to connect the respective databases separately, to copy the tedious operations of multiple projects, to reduce the hassle of deployment, and to explore the loading method of the tomcat load environment variable, so that when the project is later updated, You need to replace only one war file to achieve the effect of deploying multiple projects.
This approach also applies to scenarios for other deployment projects: when there are more environment variable parameters in properties or other configuration files in a project, a large number of configuration parameters need to be modified for each deployment project, such as: Connecting different databases, different username passwords, different upload paths in different environments, Each time you deploy a project, you need to modify the related configuration in the properties file, not only the workload, but also error prone, so the way you deploy the environment variables can greatly simplify the operation and reduce the likelihood of errors. Second, the method: 1. Add Environment Variables

Create a new ent-hlsn.xml in Tomcat, which reads as follows:

Ent-hlsn.xml

<?xml version= "1.0" encoding= "UTF-8"?> <context path= "/ent-hlsn" docbase= "E:\WorkSpace\Carbon\Enm\"
Webapp\target\com.skytech.enm.web-0.2.2-snapshot ">
<environment name=" Enterprisename value= "HLSN" type = "Java.lang.String"/>
</Context>

The file is to deploy the application under the E:\WorkSpace\ent path to Tomcat ( for deployment of applications in IntelliJ integrated Tomcat, please click here ), where environment To load a file deployment project and add "Enterprisename" as an environment variable to tomcat after starting Tomcat

(This file is the context file that was created when the project was deployed in Tomcat, under the Tomcat_home/conf/catalina/localhost path, for details see several ways of using Tomcat deployment)

2, the use of environmental variables

modifying beans in Applicationcontext.xml

Applicationcontext.xml

.....
<bean id= "Propertyconfigurer" class= "Org.springframework.context.support.PropertySourcesPlaceholderConfigurer    ">
<property name=" Ignoreunresolvableplaceholders "value=" true "/> ...
</property> </bean> .....

Where class must use Org.springframework.context.support.PropertySourcesPlaceholderConfigurer, otherwise spring cannot use the environment variables in the steps above. Propertysourcesplaceholderconfigurer is available after spring 3.1, and if you want to load environment variables in the prior 3.1 version, you need to adjust the bean configuration as follows:

Applicationcontext.xml

......
<bean id= "Propertyconfigurer" class= "Org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" &        gt;
<!--set Systempropertiesmodename for System_properties_mode_override open allow-->
<property name= " Systempropertiesmodename "value=" System_properties_mode_override "/>
<property name=" Ignoreunresolvableplaceholders "value=" true "/> ...
</bean> ...

3, testing: Testproperties.java

@Service public
class Testservice {
@Value ("${enterprisename}")
private String enterprisename;
@Value ("${enterprise.name}")
private String enterprise_name;
@PostConstruct public
void Getprop () {
System.out.println ("#################################");
System.out.println ("Enterprisename:" + enterprisename);
System.out.println ("Enterprise_name:" + enterprise_name);
System.out.println ("#################################");
}
}

By this method, the Enterprisename value "Hlsn" in Ent-hlsn.xml can be taken.

The note here @postconstruct the method that is invoked when the bean is initialized for the spring container, and if the problem with the spring configuration in the project may not be invoked, then the console cannot print the corresponding output information. So you can put the output information in the project will be called to some of the methods to test, if it is a Web application, you can also write the corresponding output statements in some methods and the corresponding operation through the page to call the output information here to achieve the test results. Of course, if the spring configuration is OK, it can be tested directly as in the example, and it can print out the corresponding environment variable information after Tomcat deploys the application.

Third, other tests:

Create a new 2 profile in the Tomcat_home/conf/catalina/localhost directory, respectively, named: Ent-jbdc.xml, Ent-sky.xml (the XML file name here is the publication name for the project deployment, optionally specified according to the name of your project), and the configuration file reads as follows:

Ent-jbdc.xml

<?xml version= "1.0" encoding= "UTF-8"?> <context path= "/ENT-JBDC" docbase= "E:\WorkSpace\Carbon\Enm\"
Webapp\target\com.skytech.enm.web-0.2.2-snapshot "workdir=" D:\APP-WORK\JBDC ">
<environment name=" Enterprisename "value=" JBDC "type=" java.lang.String "/> <environment name=" enterprise.name "value=" jbdc--
"Type=" java.lang.String "/>
</Context>

Ent-sky.xml

<?xml version= "1.0" encoding= "UTF-8"?> <context path= "/ent-sky" docbase= "E:\WorkSpace\Carbon\Enm\"
Webapp\target\com.skytech.enm.web-0.2.2-snapshot "workdir=" D:\app-work\sky ">
<environment name=" Enterprisename "value=" Sky "type=" java.lang.String "/> <environment name=" enterprise.name "value=" sky--"
Type= "java.lang.String"/>
</Context>

Start Tomcat

Iv. Summary of the test 1. Multi-Project Deployment

When Tomcat is started. The console is able to print out the environment variable values corresponding to Enterprisename and enterprise.name in different applications, indicating that there is no conflict between multiple applications 2, environment variable naming rules

Naming environment variables by enterprise.name means can also be valued, stating that the environment variable naming convention supports "." Symbol naming environment variable 3, priority

When the variable name in the properties file in the Web application is the same as the environment variable name in the previous step XML file, TOMCA prints the environment variable value configured in the XML file, so you know that the priority of the environment variable loading is higher than the properties in the XML