Comparison of several placeholder replacement project parameters, and placeholder replacement

Comparison of several placeholder replacement project parameters, and placeholder replacement

Introduction: (from: http://openwebx.org/docs/autoconfig.html)

In an application, we always encounter some parameters, such:

• Database Server IP address, port, user name;

• The directory used to save the uploaded data.

• Some parameters, such as whether to enable the cache and the key name used for encryption.

These parameters have the following commonalities:They are irrelevant to the application logic and only related to the current environment and current system users.. The following scenarios are common:

• Use different database servers in the development, testing, and release phases;

• In the development phase, A developer of Windows stores the files uploaded by users ind:\my_uploadDirectory, and B developers using Linux store the same files in/home/myname/my_uploadDirectory.

• Set during developmentcache=off, Set in the production environmentcache=on.

Obviously,These parameters are not suitable for being hard-coded in the configuration file or code.. Because every person who obtains them from the source code library may need to modify them to match their own environment.

......

Many frameworks support replacing the parameters in the configuration file with placeholder placeholders, and then reading the properties file at runtime or the compiler to complete dynamic configuration. I have recently studied several methods to replace the configuration with placeholders, so I would like to make a comparison and summary here:

------------------------- I am a split line ----------------------------

1. Configure parameters using the built-in spring object class

The Spring framework provides you with a BeanFactoryPostProcessor implementation class: org. springframework. beans. factory. config. PropertyPlaceholderConfigurer. With this category, you can remove some configuration settings. in the properties file, such an arrangement allows the XML definition file to be responsible for system settings. the properties file can be used as a custom parameter as needed.

<! -- Parameter configuration, parameter filtering, use properties to replace the placeholder --> <bean class = "org. springframework. beans. factory. config. propertyPlaceholderConfigurer "> <property name =" locations "> <list> <value> classpath: config/spring-daily.properties </value> </list> </property> </bean>

 

2. Use maven build settings to filter parameters

This is achieved by adding filters and resources to the build node. There is a <filters> tag under the <build> tag to define the location of the specified filter attribute, for example, if the filter element is assigned filters/filter1.properties, the name = value pair can be defined in this file. The value of this name = value pair can be referenced by $ {name} in the project pom, the default filter directory is $ {basedir}/src/main/fiters/

    <filters>         <filter>src/main/filters/filter-${env}.properties</filter>     </filters>     <resources>         <resource>             <directory>src/main/resources</directory>             <filtering>true</filtering>         </resource>        </resources>

　　

3. Use maven plug-in maven-war-plugin to filter parameters

You can use the maven-war-plugin plug-in to specify the environment package I want to package when executing the packaging command (the specific method is not described here ), it is easier to use than the maven native filter mechanism and has more powerful functions.

<filters>      <filter> src/main/resources/IProject-test.properties </filter>  </filters>  <plugin>      <groupId>org.apache.maven.plugins</groupId>      <artifactId>maven-war-plugin</artifactId>      <configuration>          <webResources>              <resource>                  <directory>src/main/packageFilter</directory>                  <filtering>true</filtering>                  <targetPath>WEB-INF</targetPath>              </resource>          </webResources>      </configuration>  </plugin> 

 

4. Use the AutoConfig plug-in to filter parameters

AutoConfig is similar to Maven Filtering.Tools. Is developed by Ali, a powerful parameter filter plug-in, the specific function and use method is not here to talk about, want to learn more here: http://openwebx.org/docs/autoconfig.html

 

------------------------- I am a split line ----------------------------

Comparison of four parameter filtering methods:

Method	Advantages	Disadvantages	Period of parameter replacement	Difficulty	Functionality
Spring plug-in	Fast Easy Configuration	It can only work for spring bean, and other configuration content cannot be filtered	Runtime	Low	Weak
Maven native settings	Built-in Maven functions, no additional plug-ins required	It takes effect only when the resource file is copied to the target directory. Weak Functions	Build	Medium	Weak
Maven-war-plugin	You can configure multiple environments. Overwrite the original file Flexible configuration Meet most of the requirements	Verification Mechanism missing The Build process is slow.	Build	High	Strong
AutoConfig plugin	There is a verification mechanism; Powerful functions Configuration files do not need to be packaged, so project source code files are not required	Few tutorials Difficult to get started	Build	Most complex	Strongest

 

References:

Http://www.cnblogs.com/qq78292959/p/3711501.html

Http://lishuaibt.iteye.com/blog/614783

Http://nileader.blog.51cto.com/1381108/449956

Http://openwebx.org/docs/autoconfig.html