Spring Dynamic Modules (Osgi) 开发指南

5星 · 超过95%的资源需积分: 31 85 浏览量更新于2024-07-30 收藏 1.03MB PDF 举报

"Spring动态模块开发指南" 这是一份关于Spring Dynamic Modules (SpringDM)的开发指南，由Adrian Colyer, Hal Hildebrand, Costin Leau和Andy Piper等人撰写，版权归属2006-2009年。这份文档允许在不收取任何费用的情况下自由复制和分发，但要求每份副本都包含版权声明，无论是印刷版还是电子版。在前言中，作者解释了SpringDM的重要性，并列出了使用指南的需求。首先，对于想要开始使用SpringDM的开发者，需要对Spring框架有一定的了解，同时熟悉OSGi（Open Service Gateway Initiative）平台。为了快速入门，建议尝试运行提供的示例。如果在使用过程中遇到问题，可以通过社区支持获取帮助，或者寻求专业支持。此外，还提到了如何跟踪项目的开发进度。接着，文档介绍了新版本的特性。在1.2.1版本中，重点更新包括Java 2 Security的集成，对Compendium Services的支持，Spring DM符号名称的变更，以及SpringSource Enterprise Bundle Repository (EBR)的使用。在1.1.x版本中，主要改进有Web支持、类路径资源抽象化、可插拔的扩展器配置以及更优秀的类加载机制。参考文档部分（Reference Documentation）从第8页开始，这部分将深入介绍SpringDM的各种功能和用法，包括如何构建模块化的应用程序，如何利用OSGi服务，以及如何配置和管理SpringDM的生命周期。这将是开发者理解和使用SpringDM的核心部分，涵盖了SpringDM的各个方面，如服务注册、依赖注入、模块间通信等。这份SpringDM开发指南为开发者提供了全面的指导，无论你是初学者还是经验丰富的Spring开发者，都能从中学习到如何在OSGi环境中有效地使用Spring框架，构建可扩展且模块化的应用。

5.2.2. Application Context Service Publication

Once the application context creation for a bundle has completed, the application context object is

automatically exported as a service available through the OSGi Service Registry. The context is published

under the interface org.springframework.context.ApplicationContext (and also all of the visible

super-interfaces and types implemented by the context). The published service has a service property named

org.springframework.context.service.name whose value is set to the bundle symbolic name of the bundle

hosting the application context. It is possible to prevent publication of the application context as a service using

a directive in the bundle's manifest. See Section 6.1, “Bundle Format And Manifest Headers” for details.

Note: the application context is published as a service primarily to facilitate testing, administration, and

management. Accessing this context object at runtime and invoking getBean() or similar operations is

discouraged. The preferred way to access a bean defined in another application context is to export that bean as

an OSGi service from the defining context, and then to import a reference to that service in the context that

needs access to the service. Going via the service registry in this way ensures that a bean only sees services

with compatible versions of service types, and that OSGi platform dynamics are respected.

5.3. Bundle Lifecycle

OSGi is a dynamic platform: bundles may be installed, started, updated, stopped, and uninstalled at any time

during the running of the framework.

When an active bundle is stopped, any services it exported during its lifetime are automatically unregistered

and the bundle returns to the resolved state. A stopped bundle should release any resources it has acquired and

terminate any threads. Packages exported by a stopped bundle continue to be available to other bundles.

A bundle in the resolved state may be uninstalled: packages that were exported by an uninstalled bundle

continue to be available to bundles that imported them (but not to newly installed bundles).A bundle in the

resolved state may also be updated. The update process migrates from one version of a bundle to another

version of the same bundle.

Finally of course, a resolved bundle can be started, which transitions it to the active state.

The diagram below represents the bundle states and its transitions:

Bundles and Application Contexts

Spring Dynamic Modules(1.2.1) 11

The OSGi PackageAdmin refreshPackages operation refreshes packages across the whole OSGi framework or

a given subset of installed bundles. During the refresh, an application context in an affected bundle will be

stopped and restarted. After a refreshPackages operation, packages exported by older versions of updated

bundles, or packages exported by uninstalled bundles, are no longer available. Consult the OSGi specifications

for full details.

When a Spring-powered bundle is stopped, the application context created for it is automatically destroyed. All

services exported by the bundle will be unregistered (removed from the service registry) and the normal

application context tear-down life-cycle is observed (org.springframework.beans.factory.DisposableBean

implementors and destroy-method callbacks are invoked on beans in the context).

If a Spring-powered bundle that has been stopped is subsequently re-started, a new application context will be

created for it.

5.4. The Resource Abstraction

The Spring Framework defines a resource abstraction for loading resources within an application context (see

Spring's resource abstraction). All resource loading is done through the

org.springframework.core.io.ResourceLoader associated with the application context. The

org.springframework.core.io.ResourceLoader is also available to beans wishing to load resources

programmatically. Resource paths with explicit prefixes - such as classpath: - are treated uniformly across all

application context types (for example, web application contexts and classpath-based application contexts).

Relative resource paths are interpreted differently based on the type of application context being created. This

enables easy integration testing outside the ultimate deployment environment.

OSGi 4.0.x specification defines three different spaces from which a resource can be loaded. Spring DM

supports all of them through its dedicated OSGi-specific application context and dedicated prefixes:

Table 5.1. OSGi resource search strategies

Bundles and Application Contexts

Spring Dynamic Modules(1.2.1) 12

OSGi Search Strategy Prefix Explanation

Class Space classpath: Searches the bundle classloader

(the bundle, all imported packages

and required bundles). Forces the

bundle to be resolved. This method

has similar semantics to

Bundle#getResource(String)

Class Space classpath*: Searches the bundle classloader

(the bundle and all imported

packages and required bundles).

Forces the bundle to be resolved.

This method has similar semantics

to Bundle#getResources(String)

JAR File (or JarSpace) osgibundlejar: Searches only the bundle jar.

Provides low-level access without

requiring the bundle to be

resolved.

Bundle Space osgibundle: Searches the bundle jar and its

attached fragments (if there are

any). Does not create a class loader

or force the bundle to be resolved.

Please consult section 4.3.12 of the OSGi specification for an in depth explanation of the differences between

them.

Note

If no prefix is specified, the bundle space (osgibundle:) will be used.

Note

Due to the OSGi dynamic nature, a bundle classpath can change during its life time (for example

when dynamic imports are used). This might cause different classpath Resources to be returned

when doing pattern matching based on the running environment or target platform.

All of the regular Spring resource prefixes such as file: and http: are also supported, as are the pattern

matching wildcards. Resources loaded using such prefixes may come from any location, they are not restricted

to being defined within the resource-loading bundle or its attached fragments.

OSGi platforms may define their own unique prefixes for accessing bundle contents. For example, Equinox

defines the bundleresource: and bundlentry: prefixes. These platform specific prefixes may also be used

with Spring OSGi, at the cost, of course, of tying yourself to a particular OSGi implementation.

5.5. Accessing the BundleContext

In general there is no need to depend on any OSGi APIs when using the Spring Dynamic Modules support. If

you do need access to the OSGi BundleContext object for your bundle, then Spring makes this easy to do.

The OSGi application context created by the Spring extender will automatically contain a bean of type

Bundles and Application Contexts

Spring Dynamic Modules(1.2.1) 13

剩余108页未读，继续阅读

答疑-定制-运维找我

粉丝: 42
资源: 35

Spring Dynamic Modules (Osgi) 开发指南

springDM+felix

spring dm

学习SpringDM+OSGI的总结

SpringDM开发文档

springdm开发jar

OSGi与Spring：Spring DM开发

springdm开发jar2

SpringDM笔记7-开发SpringDM Bundle

Spring权威开发指南

spring权威开发指南

最新资源