官术网_书友最值得收藏!

  • Spring Essentials
  • Shameer Kunjumohamed Hamidreza Sattari
  • 374字
  • 2021-07-16 13:05:48

Working with bean definition profiles

For commercial projects, it is a common requirement to be able to maintain two or more environment-specific configurations and beans, activated selectively only in the corresponding environment. For example, objects such as data sources, e-mail servers, and security settings could be different for development, testing, and production environments. You would want to switch them declaratively without touching the application code, keeping it externally. Developers traditionally write complex scripts and property files with separate builds to do this job. Spring comes to your rescue here with environment abstraction using bean definition profiles and properties.

Bean definition profiles are a mechanism by which application context is configured differently for different environments. You group bean definitions under named profiles in XML or using annotation and activate one or more profiles in each environment. You can set a default profile to be enabled if you do not specify one explicitly.

Let's take a look the following sample listing that configures data sources for development and production environments:

@Configuration
@ComponentScan(basePackages = "com.springessentialsbook")
public class ProfileConfigurator {

   @Bean
   @Profile("dev")
   public DataSource devDataSource() {
      return new EmbeddedDatabaseBuilder()
         .setType(EmbeddedDatabaseType.HSQL) .addScript("scripts/tasks-system-schema.sql") .addScript("scripts/tasks-master-data.sql") .build();
   }
   @Bean
   @Profile("prod")
   public DataSource productionDataSource() throws Exception {
      Context ctx = new InitialContext();
      return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource/tasks");
   }
}

Practically, for production environments, externalizing this profile config in XML would be a better idea, where you allow your DevOps team to modify it for different environments and forbid them to touch your Java code. XML configuration would look like the following listing:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:jdbc="http://www.springframework.org/schema/jdbc"
  xmlns:jee="http://www.springframework.org/schema/jee"
  xsi:schemaLocation="...">
  <!-- other bean definitions -->
  <beans profile="dev">
    <jdbc:embedded-database id="dataSource">
      <jdbc:script location="classpath:scripts/tasks-system-schema.sql"/>
      <jdbc:script location="classpath:scripts/tasks-master-data.sql"/>
    </jdbc:embedded-database>
  </beans>

  <beans profile="production">
    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
  </beans>
</beans>

You may create as many profiles as required; it is common for each developer to maintain their own configurations, with profiles named after themselves, say @Profile("mary"). You can have multiple profiles active at the same time too; it depends on how well you organize them without having conflicts or duplicate bean definitions across profiles.

Now you can activate one or more profiles as you need in each (dev, test, or prod) environment using any one of the following methods:

  1. Programmatically invoking ctx.getEnvironment().setActiveProfiles("p1", "p2", ..).
  2. Setting the property spring.profile.active—with comma-separated profile names as value—as an environment variable, JVM system property, or Servlet context param in web.xml.
  3. Add -Dspring.profile.active="p1,p2, .." as a command-line or Java argument while starting up your application.
主站蜘蛛池模板: 长顺县| 镇坪县| 五华县| 六盘水市| 桦甸市| 昭通市| 隆昌县| 陕西省| 商洛市| 得荣县| 万山特区| 读书| 东港市| 潢川县| 沅陵县| 洛隆县| 陇西县| 伊金霍洛旗| 洞头县| 扎兰屯市| 高碑店市| 积石山| 习水县| 玉山县| 垣曲县| 金塔县| 洛阳市| 太谷县| 吴堡县| 义乌市| 忻城县| 尼木县| 清镇市| 磐石市| 兴山县| 托克逊县| 孝昌县| 金平| 沭阳县| 雅江县| 闻喜县|