`
edison87915
  • 浏览: 196434 次
  • 性别: Icon_minigender_1
  • 来自: 南京
社区版块
存档分类
最新评论

Spring Profiles

    博客分类:
  • JAVA
 
阅读更多
 
首个里程碑版本 - Spring 3.1 已经发布,我们有一系列文章来讲解 Spring 的一些新特性:
  • Bean definition profiles
  • ...
  • ...
今天我们来讲解第一项 - 被称为 Bean definition profiles 的新特性。我们收到最多的请求是提供一个基于核心容器的机制,以允许在不同环境中注册不同的beans。环境一词针对不同的用户有不同的解释,不过最典型的场景是仅在性能测试环境下注册监控组件、或针对客户A和客户B的两个部署分别注册各自定制的beans。可能最常用的案例是在开发阶段使用单独的 datasource,而在 QA环境或生产环境中从 JNDI 中查找一个相同的 datasource。Bean definition profiles 是一种能够满足以上各种需求的通用解决方法,下面用一个示例来详细讲解。
 
 
Understanding the application

首先来看一个银行系统中用于示范怎样在两个帐户之间转帐的 JUnit test case。
 
public class IntegrationTests {
    @Test
    public void transferTenDollars() throws InsufficientFundsException {

        ApplicationContext ctx = // instantiate the spring container

        TransferService transferService = ctx.getBean(TransferService.class);
        AccountRepository accountRepository = ctx.getBean(AccountRepository.class);

        assertThat(accountRepository.findById("A123").getBalance(), equalTo(100.00));
        assertThat(accountRepository.findById("C456").getBalance(), equalTo(0.00));

        transferService.transfer(10.00, "A123", "C456");

        assertThat(accountRepository.findById("A123").getBalance(), equalTo(90.00));
        assertThat(accountRepository.findById("C456").getBalance(), equalTo(10.00));
    }
}
 
我们的目标很简单,从 帐户A123向帐户 C456转 10 美元。
 
典型的 XML 配置
 
bean definition profiles 也支持 @Configuration 方式的配置,在这里我们使用大家最熟悉的 XML 配置方式。
 
先不要管 bean definition profiles,考虑平时我们的 XML 配置会是怎样的。假设我们在开发阶段,一般我们会选择使用一个独立的 datasource,为了方便在这里我们使用 HSQLDB( -Spring 内存数据库( 嵌入式数据库 ) )
 
<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"
    xsi:schemaLocation="...">

    <bean id="transferService" class="com.bank.service.internal.DefaultTransferService">
        <constructor-arg ref="accountRepository"/>
        <constructor-arg ref="feePolicy"/>
    </bean>

    <bean id="accountRepository" class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>

    <bean id="feePolicy" class="com.bank.service.internal.ZeroFeePolicy"/>

    <jdbc:embedded-database id="dataSource">
        <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
        <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
    </jdbc:embedded-database>

</beans>
 
基于上面的 XML 配置,之前 JUnit test case 缺少的部分如下:
 
public class IntegrationTests {
    @Test
    public void transferTenDollars() throws InsufficientFundsException {

        GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
        ctx.load("classpath:/com/bank/config/xml/transfer-service-config.xml");
        ctx.refresh();

        TransferService transferService = ctx.getBean(TransferService.class);
        AccountRepository accountRepository = ctx.getBean(AccountRepository.class);

        // perform transfer and issue assertions as above ...
    }
}
 
当运行测试程序时,测试条会显示绿色,我们这个简单的应用和容器连接在一起,我们从容器中获取 beans 并且使用它们,这里跟平时相比没有什么特别的。当我们考虑怎样将该应用部署到 QA 环境或生产环境时问题变得有趣了。例如,一个常用的场景是在开发阶段使用 Tomcat 作为服务器( 更易用 ),但在生产环境中会将应用部署到 WebSphere 中。而在生产环境中 datasource 通常被注册到服务器的 JNDI 目录中。这意思着为了获取 datasource 我们必须要执行 JNDI 查找( JNDI lookup )。当然,对此 Spring 提供了非常好的支持,非常流行的方法是使用 Spring 的 <jee:jndi-lookup/> 元素。产生环境中的配置如下:
 
<beans ...>
    <bean id="transferService" ... />

    <bean id="accountRepository" class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>

    <bean id="feePolicy" ... />

    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>
 
上面的配置会正常工作。但问题是如何基于当前环境来切换 datasource 的配置方式呢?过去的一段时间里,Spring 的用户已经想出很多种方法来达到目的,通常都会依赖于一个系统环境变量( system environment variables )和 一个包含 ${placeholder}的<import/> 元素,通过环境变量的值来解析出正确的配置文件路径。不过这种方法不能称为一流的解决方法。
 
Enter bean definition profiles
 
概括一下上面所描述的基于环境的bean定义 - 在某些上下文中注册某些 bean。也可以说 在情况A时注册一批( a certain profile of )bean,而在情况B时注册另一批不同的 bean。
 
在 Spring 3.1 中,<beans/> XML 文档现在已经包含了这个新概念,针对上面的示例,我们可以把配置文件分为三个文件,注意 *-datasource.xml 文件中的 profile="..." 属性。
 
transfer-service.xml:
<beans ...>
    <bean id="transferService" ... />

    <bean id="accountRepository" class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>

    <bean id="feePolicy" ... />
</beans>
 
standalone-datasource-config.xml:
<beans profile="dev">
    <jdbc:embedded-database id="dataSource">
        <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
        <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
    </jdbc:embedded-database>
</beans>
 
jndi-datasource-config.xml:
<beans profile="production">
    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>
 
更新 test case,同时载入 3 个配置文件:
 
GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("classpath:/com/bank/config/xml/*-config.xml");
ctx.refresh();
 
这样还不行,当运行单元测试时我们会得到一个 NoSuchBeanDefinitionException,因为容器无法找到名为 dataSource 的 bean。原因是虽然我们明确定义了两个 profiles - dev 和 production,但我们并没有激活其中的一个 profile
 
Enter the Environment
 
在 Spring 3.1 中出现了一个新概念 - Environment。这个抽象概念贯穿于整个容器,以后的文章中会经常的看到这个概念。在这里重要的是要知道,Environment 包括了哪个 profile 正处于激活状态的信息。当 Spring ApplicationContext 加载上述三个配置文件时,会非常注意 <beans> 元素的 profile 属性,如果 beans 元素有 profile 属性,且其属性值所代表的 profile 并不是当前激活的 profile,则整个配置文件会被跳过,没有任何 bean 会被解析或被注册。
 
激活一个 profile 有多种方式,最直接的办法是使用 ApplicationContext API 以编程式的方式来实现:
 
GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles("dev");
ctx.load("classpath:/com/bank/config/xml/*-config.xml");
ctx.refresh();
 
这样当我们执行 test case 时,测试会通过。让我们看一下容器是怎样加载这三个配置文件的( *-config.xml )
  • transfer-service-config.xml - beans 元素没有 profile 属性,因此总会被容器解析
  • standalone-datasource-config.xml - 指定了 profile="div",并且 div profile 是当前激活的 profile,因此会被解析
  • jndi-datasource-config.xml - 指定了 profile="production",但 production profile 并不是激活状态,因此被跳过
 
那在真正的生产环境中如何切换为 JNDI looup 呢?当然必须要激活 production profile。像上面那样为了执行单元测试而使用编程式激活profile 的方式是非常合适的,但当部署 WAR 文件时这种方法并不适用。因此,profiles 也可以通过 spring.profiles.active 属性使用声明式激活方式,spring.profiles.active 属性值可以通过很多种方式指定:
  1. system environment variables
  2. JVM system properties
  3. servlet context parameters in web.xml

    <servlet>
      <servlet-name>dispatcher</servlet-name>
      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <init-param>
          <param-name>spring.profiles.active</param-name>
          <param-value>production</param-value>
      </init-param>

    </servlet>
  4. servlet config parameter( 即上面划线部分, 猜测 init-param 可能要添加到 Root Application Context 上才可以 )
  5. entry in JNDI
注意,profiles 并不是非此即彼的关系( 互斥 ),完全可以一次性激活多个 profile,使用编程式激活方法时,可以直接给 setActiveProfiles(String ...) 方法提供多个 profile name:
 
ctx.getEnvironment().setActiveProfiles("profile1", "profile2");
 
若使用声明式激活方法的话,spring.profiles.active 可以接收多个以逗号分隔的 profile name:
 
-Dspring.profiles.active="profile1,profile2"
 
beans 元素的 profile 属性也可以设置多个候选 profile name :
 
<beans profile="profile1,profile2">
    ...
</beans>
 
这提供了分解应用的一种灵活的方法,以便交叉分析在哪种情况下哪些 bean 会被注册。
 
 
Making it simpler : introducing nested <beans/> elements
 
目前为止,bean definition profile 给我们提供了一种方便的机制基于部署上下文/环境来决定哪些 beans 被注册,但这样引来一个问题:本来是一个配置文件,现在不得不使用3个配置文件。为了区分 profile="dev" 和 profile="production" 切割配置文件是必须的,因为 profile 属性是设置在 beans 元素上的。
 
在 Spring 3.1 中,在一个配置文件中存在嵌套的 <beans/> 元素是允许的,这意味着,我们可以仅使用一个配置文件,来实现 profile 的定义:
 
<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="...">

    <bean id="transferService" class="com.bank.service.internal.DefaultTransferService">
        <constructor-arg ref="accountRepository"/>
        <constructor-arg ref="feePolicy"/>
    </bean>

    <bean id="accountRepository" class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>

    <bean id="feePolicy" class="com.bank.service.internal.ZeroFeePolicy"/>

    <beans profile="dev">
        <jdbc:embedded-database id="dataSource">
            <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
            <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
        </jdbc:embedded-database>
    </beans>

    <beans profile="production">
        <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
    </beans>
</beans>
 
Spring-beans-3.1.xsd 已经更新,允许这种嵌套,但有一个限制条件,这些嵌套的 <beans/> 元素必须位于整个配置文件的最下面
( 作为根结点 <beans/> 元素的最后面的子元素 )。虽然这个特性是为了给 bean definition profiles 提供支持,但嵌套的 <beans/> 元素在其他情况下也非常有用,想象一下有一批 beans 需要设置为 lazy-init="true",你可以为每个 bean 都设置 lazy-init="true",但更方便的做法是直接给 <beans/> 元素设置 lazy-init="true",这样其所有的子元素bean 都会继承这个设置。而嵌套的 <beans/> 元素这一支持,使得你不需要专门为这一批 bean 创建一个单独的配置文件,直接嵌套 <beans/> 元素即可。
 
Caveats
 
使用 bean definition profiles 时有一些注意事项
 
  1. 如果有更简洁的方法来实现目的,不要使用 profiles

    如果在各个 profiles 之间唯一的变化是属性值,那么使用 Spring 已经提供的 PropertyPlaceholderConfigurer 或 <context:property-placeholder /> 可能就够了。

  2. ...
...
 
 
2014.5.6 更新

经测试,应该通过全局的 <context-param> 来激活 profile, 通过上文中的 <init-param> 方式并不能激活相应的 profile
 
<context-param>
    <param-name>spring.profiles.active</param-name>
    <param-value>dev</param-value>
</context-param>
 
使用 web.xml 的 <context-param> 来激活 profile 有个缺点, 当环境变化时( test/dev/product )需要频繁的更改 web.xml 文件.
尤其当使用西部数码 Java 虚拟主机的 Tomcat 时, 只能对 server.xml 进行配置, 其他配置文件( 包括共享的 web.xml 文件 )是没权限碰的, 下面是使用 server.xml 中 Context#Parameter 配置来取代 <context-param> 方法, 实际上 server.xml#Context#Parameter 与 web.xml#context-param 的效果是完全一样的, 具体请参考下面的官方资料:
( server.xml )Context Parameter
 
配置也很简单, ( server.xml )如下:
 
<Context docBase="..." path="" .../>
    <Parameter name="spring.profiles.active" value="product"/>
</Context>
 
针对不同环境的 Tomcat, 分别给 Context ( 容器 )设置相应的 Context Parameter, 这样, 同一个应用就可以在代码不变的情况下部署到各个环境中, 并且能够自动激活当前环境对应的 profile 了
 
另外, 测试时使用 Jetty 服务器我感觉比 Tomcat 要方便很多, 一般使用 Eclipse + RunJettyRun, 此时, server.xml#Context#Parameter 这种方式明显不适合 Jetty, 来看一下如何配置:


 
 
还有个小技巧, 如果测试 / 开发环境都使用 Jetty, 可以在上图中, 右键项目 -> Duplicate 复制一份, 然后配置各自的 Environment 来激活不同的 profile 即可.
 
2014.5.22 更新

激活 Profile 的关键元素有哪些?看源码
 
org.springframework.core.env.StandardEnvironment
/** System environment property source name: {@value} */ 
 public static final String SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME = "systemEnvironment";
 
 /** JVM system properties property source name: {@value} */
 public static final String SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME = "systemProperties";
 
@Override
protected void customizePropertySources(MutablePropertySources propertySources) {
    propertySources.addLast(new MapPropertySource(SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME, getSystemProperties()));
    propertySources.addLast(new SystemEnvironmentPropertySource(SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME, 
        getSystemEnvironment())); 
 }
StandardEnvironment 的子类 StandardServletEnvironment
 /** Servlet config init parameters property source name: {@value} */ 
 public static final String SERVLET_CONFIG_PROPERTY_SOURCE_NAME = "servletConfigInitParams";
 
/** Servlet context init parameters property source name: {@value} */
 public static final String SERVLET_CONTEXT_PROPERTY_SOURCE_NAME = "servletContextInitParams"; 
 
 /** JNDI property source name: {@value} */
 public static final String JNDI_PROPERTY_SOURCE_NAME = "jndiProperties";
 
@Override
 protected void customizePropertySources(MutablePropertySources propertySources) {
  propertySources.addLast(new StubPropertySource(SERVLET_CONFIG_PROPERTY_SOURCE_NAME));
  propertySources.addLast(new StubPropertySource(SERVLET_CONTEXT_PROPERTY_SOURCE_NAME));
  if (JndiLocatorDelegate.isDefaultJndiEnvironmentAvailable()) {
   propertySources.addLast(new JndiPropertySource(JNDI_PROPERTY_SOURCE_NAME));
  }
  super.customizePropertySources(propertySources);
 }
 
  • 大小: 60.3 KB
分享到:
评论
2 楼 yhxf_ie 2017-04-12  
完全不懂.. 
1 楼 cocoa_cactus 2016-03-15  
很有收获!之前一直不明白为什么要用beans标签,thanks a lot!

相关推荐

Global site tag (gtag.js) - Google Analytics