 
- 帖子
- 864
- 精华
- 62
- 积分
- 4682
- 最后登录
- 2011-12-21
|
2#
发表于 2011-11-30 15:35
| 只看该作者
在部署过程中存储应用时,Cloud Foundry将进行两处修改:
1. 在包含BeanFactoryPostProcessor以及相关资源的应用中增加额外的jar包。请注意用于自动重新配置的jar包版本与cloudfoundry-runtime相关。然而,某些类会通过着色机制重新迁移到不同的包中。这样一来,应用就能够使用不同版本的jar包而不会产生冲突。
2. 修改web.xml文件更新组成Spring应用上下文的文件,在web.xml中添加BeanFactoryPostProcessor。
局限性
自动重新配置服务只有在以下两种情况下才起作用:
1. 每一种服务类型只能绑定一种服务,例如,你只能为应用绑定一种关系数据库服务(MySQL或Postgres)。
2. 每个bean的匹配类型只能有一个。例如,在应用上下文环境中只能有一个DataSource bean。
如果应用不满足上述限制条件的话,那么自动配置机制就不能生效。在这种情况下你可能需要使用命名空间,该部分内容我们会在下一篇文章中进行介绍。
自动重新配置机制要求典型的Spring应用。如果应用上下文环境过于复杂,那么自动配置机制可能不会生效。在这种情况下,你可以选择退出自动重新配置。
选择退出自动重新配置
有些情况下,你可能想退出自动重新配置。例如,你有一个在内存中运行的关系数据库,这时便不需要与Cloud Foundry服务进行绑定了。Cloud Foundry提供了一些方法能够退出自动重新配置机制。
1. 部署应用时选择"JavaWeb"框架。这会将你的应用视作非Spring应用,这时你的应用将保持不变(不会在应用中添加jar包,也不会对web.xml文件进行修改。)同时也意味着在该系列文章中所讨论的配置文件特性对该类应用将不可用。
2. 使用任一元素创建代表服务的bean。目前元素包括, , ,以及。如果应用恰好包括了基于这些命名空间元素底层类型的bean的话(比如CloudMongoDbFactoryBean),那么选择退出自动重新配置将会生效。
Cloud Foundry使用该机制选择退出,这样应用就可以选择进行自动重新配置也可以完全控制服务创建。我们没有看到过采用自动重新配置配置某些服务,然后手动配置其他服务的情况。
结论
Cloud Foundry提供的自动重新配置功能是一个很棒的起始创建方式。如果应用日趋成熟或者需要绑定多个服务,那么你可能需要对服务连接对象进行更好的控制。这时候 命名空间就派上用场了。在该系列文章的下一篇文章中,Thomas Risberg将讲解如何使用 命名空间。 |
|