Spring动态模型参考指南1.0.1

Spring动态模型（SpringDynamicModules）参考指南1.0.1AdrianMColyer(SpringSource),HalHildebrand(Oracle),CostinLeau(SpringSource),AndyPiper(BEA)Copyright©2006-2008若不作商业用途，且保证无论是印刷版还是电子版的所有副本中均包含此版权说明，则本文的副本可供个人或分发给他人使用。译者前言国际歌(法)鲍狄埃词(法)狄盖特曲起来饥寒交迫的奴隶起来全世界受苦的人满腔的热血已经沸腾要为真理而斗争旧世界打个落花流水奴隶们起来起来不要说我们一无所有我们要做天下的主人这是最后的斗争团结起来到明天英特纳雄耐尔就一定要实现这是最后的斗争团结起来到明天英特纳雄耐尔就一定要实现从来就没有什么救世主也不靠神仙皇帝要创造人类的幸福全靠我们自己我们要夺回劳动果实让思想冲破牢笼快把那炉火烧得通红趁热打铁才能成功这是最后的斗争团结起来到明天英特纳雄耐尔就一定要实现这是最后的斗争团结起来到明天英特纳雄耐尔就一定要实现是谁创造了人类世界是我们劳动群众一切归劳动者所有哪能容得寄生虫最可恨那些毒蛇猛兽吃尽了我们的血肉一旦把他们消灭干净鲜红的太阳照遍全球这是最后的斗争团结起来到明天英特纳雄耐尔就一定要实现这是最后的斗争团结起来到明天水平有限，精力有限，望不吝指教，共同完善之。翻译：蔡超伟：[e-mail]2008年4月前言近年来应用程序开发的发展变化显著：更简洁、更轻便和基于POJO（译者注：PlainOldJavaObject的缩写）的编程模式——这些发展都是为了保持较快的开发速度。依赖注入和面向方面编程，这些新生的活跃而具争议的想法被大多数开发者日常用于管理和简化他们的应用程序的复杂性。然而在应用程序部署方面，情况并无长足进展。尽管代码被分成一个个的模块，但无论从逻辑上、概念上还是物理上，在运行时看来它们是一个单块集成电路般的应用程序，进行任何改动（或大或小）都需要重启。OSGi的目标就是通过拆分应用程序改变这种状况——它允许应用程序被分成若干个独立模块，这些模块具有不同的生命周期、依赖性却一如既往地严丝合缝。SpringDynamicModules致力于整合Spring框架和OSGi平台：前者有强大、低依赖性编程模型和概念，后者具有动态性、模块性，Spring-DM集两家之长，它允许透明地导出和导入OSGi服务、进行生命周期管理和控制。尽管我们尽力想保证这份文档的可读性和准确性，然而某些主题可能需要更多的解释、一些笔误可能不经意地发生。如果您发现任何问题或者严重错误，您不妨抽个小空把问题提交到SpringDynamicModules开发组，不胜感激。第1部分绪论此文档是SpringDynamicModules的参考文档，它定义了SpringDynamicModules的概念和语义，OSGi服务平台（OSGiServicePlatform）的语法基于命名空间，DynamicModule定义了DynamicModule扩展Bundle和OSGiMANIFEST头条目。关于使用DynamicModule构建基于OSGi的应用程序的入门指南，请访问我们的在线网页。需要Spring介绍的OSGi开发者可以回顾一下springframework.org网站上的介绍文档。注意：OSGi是OSGi联盟的商标，联盟尚未昀终决定工程名称。注意：请查看《SpringDynamicModulesRelease已知问题》（spring-dm-issues.pdf）文档。第1章.为何使用SpringDynamicModules（WhySpringDynamicModules）？Spring框架是一套领先而完备的Java/JEE应用框架。它提供一个轻量级的容器和一种非侵入编程模型，它基于依赖性注入、AOP和可移植服务抽取。OSGi服务平台提供一个动态应用程序执行环境，在这个环境里模块（bundles）可以被即时地安装、更新或者移除。它同样对模块性和版本控制有着优秀的支持。SpringDynamicModules使得编写一个可部署在OSGi执行环境下的Spring应用程序变得很轻松，同时它也可以利用OSGi框架提供的服务。由于Spring框架的简单易用和强大，Spring对OSGi的支持同样使得OSGi应用程序的开发变得更简单和高产。对企业级应用，SpringDynamicModules和OSGi平台的整合提供如下特性：„更好的模块间的应用逻辑隔离，这些模块具有运行时强制的模块边界„同时部署同一个模块（或库）的不同版本的能力„动态发现和使用系统内其他模块提供的服务的能力„在运行着的系统中动态地安装、更新和卸载模块的能力„使用Spring框架在模块内部和模块之间进行实例化、配置、整合组件的能力„对于企业级开发人员来说是一个简单和熟悉的编程模型，便于利用OSGi平台的特性我们相信OSGi和Spring的结合将为构建企业应用程序提供一个方便易懂的模型。第2章.环境需求（Requirements）SpringDynamicModules1.0支持JDK1.4及更高版本，OSGiR4及更高版本。使用SpringDynamicModules来发布的Bundle必须在manifest（OSGiR4）中说明Bundle-ManifestVersion:2。我们在Equinox3.2.2，elix1.0.1和Knopflerfish2.0.3下进行测试和持续集成。第2部分参考文档文档结构在这一部分中，参考文档将解释说明SpringDynamicModules所提供的核心功能。第3章．Bundles和ApplicatonContexts(BundlesandApplicationContexts)——本章描述OSGiBundle和Spring应用上下文之间的关系，同时还介绍SpringExtenderBundle对应用上下文自动实例化的支持。第4章．打包和部署基于Spring的OSGi应用程序(PackagingandDeployingSpring-basedOSGiapplications)——本章描述如何在OSGi环境下部署Spring框架jar文件，如何在你的应用程序Bundle里引用外部API函数。本章还解释了在OSGi环境中使用当前并不是为OSGi设计的企业类库时遇到的一些问题。第5章．服务注册(TheServiceRegistry)——本章描述在OSGi服务注册中如何把SpringBean作为服务导出。本章还定义了如何支持OSGi服务和Bundle的动态生命周期。第6章．使用Bundle(WorkingwithBundles)——本章描述如何声明一个表现为OSGiBundle的Bean，包括如何向OSGi平台上安装新包第7章．测试基于OSGi的应用程序(TestingOSGibasedApplications)——本章介绍了SpringDynamicModules支持的集成测试。你可以运用它来编写简单Junit集成测试用例：可以启动OSGi环境，安装集成测试所需Bundle，在OSGi里运行测试用例，并且返回结果给用户。这些使得把OSGi集成测试整合进任何支持Junit的环境里变得简单方便。第3章.Bundles和ApplicationContexts(BundlesandApplicationContexts)bundle是OSGi的部署(和模块)单元(见《OSGiServicePlatformCore规范》3.2)。在OSGi运行时里的bundle具有如下三种状态：installed，resolved，active。Bundle可以输出服务（对象）到OSGi服务注册表里，并且使这些服务对其他bundle可用。Bundle也可以输出Java包，供其他bundle来导入它所输出的类型。在Spring中昀主要的单元模块是应用程序上下文（applicationcontext），在应用程序上下文里包括了一些bean（被Spring的应用程序上下文所管理的对象）。应用程序上下文可以被配置成具有层次关系，这样一个子应用程序上下文可以使用其父上下文定义的bean，反之却不行。Sping中的输出器Bean和工厂Bean用于将bean的引用输出到应用程序上下文之外的客户端中，并且将服务的引用注入到客户端中。在OSGibundle和Spring应用程序上下文之间有很自然的紧密联系。使用SpringDynamicModules，一个active的bundle可以包含一个Spring应用程序上下文，它负责在bundle里实例化、配置、组装和装饰对象（bean）。这些bean即可作为OSGi服务输出而提供给其他bundle，也能透明地注入其他OSGi服务的引用。3.1.SpringDynamicModules扩展器（Extender）包SpringDynamicModules提供了一个OSGibundle：org.springframework.osgi.bundles.extender，这个bundle负责为应用程序Bundle实例化Spring应用程序上下文。它的功能和用于Springweb应用程序的ContextLoaderListener()一样。一旦extenderbundle被安装和启动，它就会寻找所有具有Spring权限且已经在ACTIVE状态的bundle，并且替它们创建应用程序上下文。另外extenderbundle还监听bundle启动事件和为所有后启动的具有Spring权限的bundle创建应用程序上下文。在4.1部分，“bundle格式和Manifest头条目”描述了extenderbundle怎样识别“具有Spring权限的bundle”3.2.创建应用程序上下文（ApplicationContext）extenderbundle异步地创建应用程序上下文。这样是的OSGi服务平台能快速地启动，而且不会导致具有内部依赖性服务的bundle在启动时死锁。一个具有Spring权限的Bundle可在其应用程序上下文创建之前把状态变成STARTED。可以强制按一定顺序同步地创建bundle的应用程序上下文。在4.1部分，“bundle格式和Manifest头条目”，描述了定义这种行为的方法。如果由于某种原因而导致应用程序上下文创建失败，那么失败原因将会被记日志。bundle仍然在STARTED状态。这样不会有服务会从应用程序上下文注册到服务注册表。强制服务依赖性如果一个应用程序上下文声明了对一个OSGi服务是否可用的强制依赖性（见第5章“服务注册表”），那么该应用程序上下文的创建会被阻塞，直到匹配的服务在OSGi服务注册表里可用，强制依赖性被满足。由于在OSGi环境里一个服务可能被随时安装和卸载。这种阻塞行为只能保证在应用程序上下文创建的时候强制依赖性的服务可用。在应用程序上下文创建的过程中，服务可能随后再次变得不可用。第5章“服务注册表”将会介绍当一个强制依赖的服务引用变得unsatisfied时会发生什么。在实际情况下，对于大多数使用SpringDynamicModules服务来构建的企业应用程序来说，在平台和所有安装的bundle都启动后，可用服务和bundle集将会达到一个稳定的状态。在这种情况下，如果Abundle依赖Bbundle输出的服务，那么等待强制依赖服务的行为只需简单地确保Abundle和Bbudle可以任意启动即可。等待强制依赖服务可用具有一个超时时长，默认为5分钟，但是也可以通过timeout属性直接定义该值，详见4.1部分“Bundle格式和Manifest头条目”。如果不是所有强制依赖的服务在启动时都可用，那么这有可能改变应用程序上下文创建的语义，这样会