- 浏览: 546137 次
- 性别:
- 来自: 西安
文章分类
- 全部博客 (251)
- UML/RUP/软件工程 (0)
- DDD:领域驱动设计 (1)
- IaaS/Paas/SaaS (1)
- Hadoop/YARN (10)
- PBDP项目 (2)
- OSGi-基础 (7)
- OSGi-Aries (2)
- OSGi-SpringDM (32)
- Oracle/MySQL/SS (8)
- Felix/Equinox/Bnd (14)
- Virgo Server/Gemini (7)
- Weblogic/JBoss/Tomcat (10)
- ActiveMQ (14)
- Camel (1)
- Spring Roo/Eclipse (7)
- Java/JSP/JSF (10)
- Maven (19)
- ESB-Mule (1)
- ESB-ServiceMix (18)
- SOA/SCA/SDO (12)
- WebService/RESTful (17)
- JS/jQuery/ExtJS (4)
- Spring/JPA/MVC (15)
- SpringSecurity (5)
- BPM/jBPM (3)
- Hudson/SVN/CI (0)
- LinuxOS/虚拟化 (25)
- Office/OpenOffice (1)
- 项目管理 (5)
- POI/jFreeChart (1)
最新评论
-
panamera:
请问JMS Transport 发布的webservice 是 ...
CXF 提供的Service Transport-JMS Transpor -
jianyi296:
where is attachment.
CXF WebService Dynamic Client -
hj01kkk:
您好,我用jdbc-user-service为什么每次验证时都 ...
SpringSecurity笔记3-Authenticating Users:Authenticaton Strategy -
wufenglin1231:
你好,我在实现Mapping exceptions to re ...
RESTful 异常处理 -
xchd:
[echo] Project: common
[echo ...
Hive安装配置学习笔记
扩展模型指一个Bundle在扫描其他Bundle内容的过程中,该Bundle代表被扫描Bundle执行其Action. 而在SpringDM中,扩展模型指当在MANIFEST.MF文件或Bundle的内容中有指定的扩展存在时,SpringDM应该自动
的触发连锁的事件(Event),即创建Spring Context, 该Context包括一个特指的类型上下文:OsgiBundle-
XmlApplicationContext.
任何部署到OSGi环境中的Bundle,SpringDM将检查该Bundle的SpringDM触发点,如果找到该出发点,该
Bundle将被赋予一个OsgiBundleXmlApplicationContext 类型的上下文;如果没找到触发点,SpringDM日志
将输出日志:
No Application context created for bundle<bundle_name>
但是扫描仍将继续。
SpringDM中有两中类型的Extender: Stand Extender和Web Extend,用于创建Context的默认Trigger如下:
Stand Extender:
/METa-INF/spring/*.xml: 放置与搞目录下的xml配置文件将用于SpringContext的创建;
Spring-Context mainfest value:这是一种更细粒度度的控制SpringContext的创建;
Web Extender:
.war bundle extension: 以.war作为扩展名表明该Bundle将被部署一个Web应用。
The stand extender primarily listens for bundle starting events, but it also looks for Spring-powered bundles that are already in the active state when it is itself started.
The default extender behavior is to retrieve the Spring configuration files from the bundle space, as it’s defined in the OSGi specification.
1. 标准的SpringOSGi组件的结构
1.1 DEFAULT BEHAVIOR FOR LOCATING SPRING CONFIGURATION FILES
my-springpowered-bundle.jar
META-INF/
MANIFEST.MF
spring/
application-context-1.xml
application-context-2.xml
com/
manning/
sdmia/
...
1.2 DEFINING THE LOCATION OF SPRING CONFIGURATION FILES WITH THE SPRING-CONTEXT
HEADER
Spring-Context: config/app-context-1.xml, config/app-context-2.xml
Spring-Context: config/*.xml
Spring-Context: config/**/*.xml
如果一个Bundle中同时有上述两种配置方式存在,则第二种优于第一种;如果一个Bundle 有Fragement,则
Fragement中的配置优于Host Bundle中得配置。
1.3 SPRING DM’S RESOURCE LOCATION BEHAVIOR
Spring Resource Abstraction
The Spring Framework defines an abstraction to load resources from an application context. This
abstraction is based on the Resource interface, which represents the access to a resource and is
agnostic to the underlying resource medium (filesystem, classpath, URL, and so on). Spring
defines the ResourceLoader interface, which is meant to be implemented by objects that can load
resources (a Spring application context always implements this interface).
Spring supports several prefixes: classpath, file, http.
Spring DM introduces a new Resource implementation, OsgiBundleResource , which encapsulates
all the necessary logic for proper resource loading from a bundle in an OSGi environment.
OSGi resource search strategies with Spring DM:
(1)OSGi search strategy:Class space
Prefixes:classpath:,classpath*:
Description:Search is delegated to the bundle classloader. The bundle itself, imported packages,
and required bundles are then scanned using the same semantics as the Bundle.getResource
method.
(2)OSGi search strategy:JAR file
Prefixes:osgibundlejar:
Description:Only the bundle itself is scanned, using the same semantics as the Bundle.getEntry
method.
(3)OSGi search strategy:Bundle space
Prefixes:osgibundle:
Description:The bundle and its fragments (if any) are scanned. Delegates internally to the
Bundle.findEntries method. This is Spring DM’s default resource-loading strategy.
配置示例:
Spring-Context: config/application-context.xml
Spring-Context: osgibundle:config/application-context.xml
这两种配置在OSGi环境中是等价的。
<bean id="someBean" class="com.manning.sdmia.SomeBean">
<property name="resource" value="classpath:help/section1.html" />
</bean>
1.4 ORGANIZING SPRING CONFIGURATION FILES IN A BUNDLE
A typical Spring-powered bundle of this sort would have the following structure:
my-springpowered-bundle.jar
META-INF/
MANIFEST.MF
spring/
modulename-context.xml
modulename-osgi-context.xml
com/
manning/
sdmia/
...
2. Bundle中初始化和销毁Spring容器
When the Spring DM extender is started, it scans the OSGi container for bundles in the active
state and bootstraps the application contexts for those it identifies as Spring-powered.
The Spring DM extender creates application contexts asynchronously; application contexts are
started in a different thread than the one that started the bundle (usually a thread owned by the
OSGi platform).
SpringDM在不同的线程中创建上下文主要有以下两个原因:
(1)OSGi规范推荐Event尽力在短时间 内进行,而创建应用上下文是需要时间的,如果创建应用上下文发生在OSGi
Event线程中,它将会阻止平台中其他任务的运行从而减缓了容器的启动;
(2)创建一个应用上下文时,The Extend Bundle需要应用上下文中Service的依赖被满足;如果创建上下文这个
任务是同步执行的,那么Bundle启动的顺序就需要很仔细的管理,要避免Service之间循环依赖现象发生。
The Spring DM extender is a bundle listener!
In Spring DM 1.2, the extender is a synchronous bundle listener, registered by the activator of the
Spring DM extender bundle. What exactly is a synchronous bundle listener? It’s an
implementation of the observer pattern , which allows code to react to bundle events, such as
activation, startup, or stopping. There are two kinds of bundle listeners, synchronous and
asynchronous (represented by two interfaces, SynchronousBundleListener and BundleListener
respectively), and the way the OSGi platform notifies them is slightly different.
Synchronous listeners receive more events than their asynchronous brethren (兄弟), as they’re
notified of starting and stopping events (the targeted bundle is on the way to being started or
stopped, respectively). Second, they’re called during the processing of the event . In the case of
bundle startup, the caller asks the platform to start the bundle, the platform notifies the
synchronous listeners, each does its work, and the bundle is started (and then the platform
broadcasts a started event, but that’s another story). With the synchronous method, listeners are
always notified during the processing of the event.
Asynchronous bundle listener notification isn’t as straightforward as the synchronous case. The
OSGi platform doesn’t place any constraints on the timeliness of notification and can add events
to a queue and let a background thread dispatch them to the asynchronous listeners. There is no
guarantee that event ordering is respected (the started event of the bundle could be delivered
after the corresponding stopped event). This doesn’t make asynchronous listeners useless, but
the dispatch mechanism needs to be understood when writing listeners of this type!
The BundleListener and SynchronousBundleListener interfaces define the same method, the
synchronous flavor being simply a marker-based extension of the asynchronous interface.
Synchronous bundle listeners must be used with caution, because they can slow the whole
platform if their processing takes too much time. The Spring DM extender is a synchronous
bundle listener but it delegates the creation of Spring application contexts to different threads by
default.
3. HOW SPRING DM DESTROYS APPLICATION CONTEXTS
The Spring DM extender takes care of the destruction of application contexts (on stopping bundle
events ) and accomplishes this crucial operation in a managed and safe way.
Through application context destruction, Spring DM accomplishes the following things:
■ Calls the shutdown method on Spring beans
■ Unregisters exported services
■ Informs the OSGi container that imported services are no longer used
The destruction is handled synchronously : the OSGi container is told to stop a Spring-powered
bundle, it sends a stopping event, the Spring DM extender receives the event and stops the
bundle application context (in the same thread ), and then control returns to the container, which
then stops the bundle.
The destruction is done synchronously because the application context must be destroyed before
the bundle is stopped. Once stopped, a bundle—and in particular, its bundle context—can’t be
used anymore.
4. STOPPING THE EXTENDER
Stopping the extender consists of destroying the application contexts in the right order . Why must
there be a “right” order? Well, application contexts can have dependencies on each other; some
can export services that others consume. The right order is therefore based on the way bundles
are connected through the service registry. Spring DM must compute the dependency graph of
Spring-powered bundles by analyzing their service relationships.
解决依赖关系的SpringDM的算法:
Spring DM would first track bundles that either don’t export any services, or export services that
aren’t referenced (used). These bundles are destroyed immediately (although Spring DM will
additionally attempt to do this in the reverse order of their creation) and whatever services
they’re using are released. The services these bundles were using might then no longer be
referenced, and Spring DM would find their owning bundles and destroy their application contexts.
This cycle continues until there are no more application contexts left to shut down.
解决循环依赖关系:
In this case, Spring DM has no choice other than to break the cycle by trying to find the most
appropriate bundle to stop first. Spring DM bases its choice on an OSGi property of services: the
service ranking . Services are looked up from the service registry by their interface. In the case
that there are several services implementing the same interface, the one with the highest service
ranking is returned by the OSGi platform. For each remaining bundle, Spring DM finds the highest
service ranking number and destroys the application context whose bundle has the lowest service
ranking among the set just calculated. If there is a tie in lowest ranking, Spring DM uses the
bundle ID (an indicator of start order) as a tiebreaker, stopping the bundle with the highest ID
(which was thus started last). This will hopefully break the cycle, and Spring DM can restart its
algorithm at the beginning to find other application contexts to destroy.
5. Customizing application context creation
Directives for the Spring-Context header:
配置文件默认值:
Bundle-Context:*;
Spring-Context:*;
配置文件默认路径:
/META-INF/spring,如果指定了其他配置文件路径,默认路径将被忽略。
(1)Directive:create-asynchronously
Possible values:true, false
Description:Tells the extender to create the bundle application context asynchronously or
synchronously. Default is true (asynchronously).
(2)Directive:wait-for-dependencies
Possible values:true, false
Description:Controls whether application context creation should wait for all mandatory imported
services to be available. Default is true.
(3)Directive:timeout
Possible values:integer
Description:Indicates the time (in seconds) to wait for mandatory imported services to become
available before failing the creation of the application context. Default is 300 seconds (5 minutes).
(4)Directive:publish-context
Possible values:true, false
Description:Controls whether the bundle application context is published in the OSGi service
registry. Default is true.
5.1 CREATE-ASYNCHRONOUSLY
By setting the create-asynchronously directive to false, the creation of the application context
occurs in a thread managed by the OSGi platform,how to set the create-asynchronously
directive:
(1) 用默认的配置路径异步创建上下文(默认值):
Spring-Context: *;create-asynchronously:=true
(2) 指定配置文件路径同步创建上下文:
Spring-Context: config/application-context.xml;create-asynchronously:=false
5.2 WAIT-FOR-DEPENDENCIES
默认值:Spring-Context: *;wait-for-dependencies:=true
Spring-Context: config/application-context.xml;wait-for-dependencies:=false
With this setting, mandatory dependencies are treated as optional, and Spring beans using them
will be injected with a service proxy that isn’t currently backed by an actual service retrieved
from the service registry.
推荐异步创建,同步情况下有可能导致依赖死锁。
5.3 TIMEOUT
默认值:Spring-Context:*;timeout:=300
Spring-Context: config/application-context.xml;timeout:=120
With this setting, an application context will wait for its mandatory dependencies for 300 seconds
before the creation attempt fails. The timeout directive makes sense only when application
contexts wait for their mandatory dependencies, so it’s ignored when the wait-for-dependencies
directive is set to false。
5.4 PUBLISH-CONTEXT
默认值:Spring-Context:*;publish-context:=true
Spring-Context: config/application-context.xml;publish-context:=false
指从Bundle配置文件路径中创建上下文,但是不将该上下文作为一个服务注册至OSGi 注册中心。
发表评论
-
SpringDM笔记31-Testing with OSGi and SpringDM
2011-11-22 10:27 12481. 创建一个SpringDM测试类 SpringD ... -
SpringDM笔记30-OSGi中使用SSL/STL
2011-11-21 11:55 1320SSL:Secure Sockets Layer ... -
SpringDM笔记29-Require-Bundle与Import-Package的区别
2011-11-21 10:31 2245具体可参考:http://www.osgi.org/bl ... -
SpringDM笔记28-OSGi Bundle Activities with Spring-DM
2011-11-17 10:19 1164OSGi框架中也支持搞层次的模块交互:bundles.例如 ... -
SpringDM笔记28-Spring And OSGi:Layers of Integration
2011-11-15 11:00 11791. Application Design:Service和B ... -
SpringDM笔记27-Extending The Stand Extender and Configure
2011-09-02 09:38 8721. -
SpringDM笔记25-Using AJAX frameworks with Spring DM:GWT
2011-09-01 08:53 12041. Using Spring DM with AJAX fr ... -
SpringDM笔记24-Using action-based web frameworks with Spring DM:SpringMVC
2011-08-30 09:33 1481■ Action-based web frameworks ... -
SpringDM笔记23-Using the open EntityManager in view pattern实现延迟加载
2011-08-30 09:27 15701. The open EntityManager in vi ... -
SpringDM笔记22-Transactions Support With SpringDM
2011-08-29 21:24 12151. Spring’s transactional suppo ... -
SpringDM笔记21-Using ORM within OSGi with Spring DM
2011-08-25 10:31 2098Version 1.Object/relational ma ... -
SpringDM笔记20-Using JDBC within OSGi with Spring DM
2011-08-25 09:08 1779The public API for interact ... -
SpringDM笔记19-SpringDM如何处理OSGi应用的动态行为
2011-08-24 08:51 1146ServiceTracker 1. Dealing ... -
SpringDM笔记18-Designing OSGi Enterprise Applications
2011-08-22 11:08 11241. Organizing OSGi components ... -
SpringDM笔记17-Handling Collections of OSGi Services
2011-08-20 09:12 15431.Configuring collections:the l ... -
SpringDM笔记16-处理OSGi服务的动态性:事件
2011-08-19 09:51 17861. Service registration and unr ... -
SpringDM笔记15-通过声明特定的属性注册和引用服务
2011-08-18 11:01 14091. Configuration for registerin ... -
SpringDM笔记14-The thread context classloader 及在OSGi中的运用
2011-08-18 10:40 22511. Using the thread context cla ... -
SpringDM笔记13-OSGi服务注册与引用
2011-08-18 09:28 34511. Combining OSGi services and ... -
SpringDM笔记12-Spring DM’s web Extender运行机制
2011-08-17 11:04 2089SpringDM把一个WAR作为一个Bundle, 其实 ...
相关推荐
spring-osgi-extender-1.2.1.jar spring-osgi-extender-1.2.1-sources.jar spring-osgi-io-1.2.1.jar spring-osgi-io-1.2.1-sources.jar spring-osgi-mock-1.2.1.jar spring-osgi-mock-1.2.1-sources.jar spring-...
内含57.4PIN_MAP,包括应用的例程,值得参考。需要57.4引脚定义的速速下载
VNDB Extender的更新版本 新的功能: 旧版视图:允许暂时禁用VNDB Extender 同步加载:帮助防止大量请求导致的VNDB阻止 VN列表支持:现在,您可以在主VNDB列表中使用VNDB扩展器。 VNDB查询模式:现在,VNDB ...
grunt-responsive-images-extender, 使用srcset和尺寸属性扩展HTML图像标签的Grunt插件 grunt-responsive-images-extender使用srcset扩展HTML图像标记,并使用大小属性来利用本机响应图像。正在启动这个插件需要 ...
单片机串入并出源程序,已经调试成功,可以直接使用
本人自己翻译的Burp Suite 专业版的中文手册,陆续更新,请期待
Net Search Extender提供给用户一种使用SQL查询来搜索文档的快速、通用和迅捷的方法。
TNT Realtime DOS-Extender 支持DOS下多线程序的运行时程序。 微软的 Foxpro 的32位版本程序,就是使用本产品开发。 FOXPROX.EXE 是 Foxpro 的32位版,一个文件即可完美运行所有的 Foxpro 功能。 TNT DOS-...
Burp Extender API-非官方的Kotlin版本 非官方Kotlin版本,用于利用Burp的核心功能来构建用户扩展( )。目的API的Kotlin版本允许Burp扩展完全用Kotlin编写。起源这些源代码文件是使用IntelliJ的Java转换为Kotlin...
org.springframework.osgi.extender-1.2.1.jar
TNT Realtime DOS-Extender 支持DOS下多线程序的运行时程序。 微软的 Foxpro 的32位版本程序,就是使用本产品开发。 FOXPROX.EXE 是 Foxpro 的32位版,一个文件即可完美运行所有的 Foxpro 功能。 TNT DOS-...
TNT Realtime DOS-Extender 支持DOS下多线程序的运行时程序。 微软的 Foxpro 的32位版本程序,就是使用本产品开发。 FOXPROX.EXE 是 Foxpro 的32位版,一个文件即可完美运行所有的 Foxpro 功能。 TNT DOS-...
Composer安装程序扩展器composer-installers-extender是的插件,它允许逐个软件包将任何软件包安装到项目中默认vendor目录以外的目录。 该插件扩展了插件,以允许其自定义安装程序处理任何任意软件包类型。 插件具有...
运行go build -o ./builds/extender ./cmd/extender.go 用 要求 PostgreSQL Centrifugo(WebSocket服务器) 设置 使用database目录中的数据库迁移 构建并将编译的文件移动到目录/opt/minter/extender 将.env....
提供POP3服务
开源项目-gomatic-extender.zip,Go toolchain subcommand extender - allows for easily adding to or overriding go subcommands by just adding a go-* executable to the path.
自述文件 Burp Extender python插件可即时解密和加密AES加密后的参数。 这只是我用于特定移动应用程序的一个迷你项目,所以请不要尝试判断代码质量。 :D 有关详细信息: :
VisendoSMTPExtender,一款免费的POP服务器搭建软件。。。。。。。。。。。。。。。。。。
Google Chat Extender 这个插件可让您自定义您的Google聊天应用! 新的自定义主题和插件! 如何在这里找到我想要的? 很简单! 插件您可以在plugins文件夹中找到所有插件。 您可以在主题文件夹中找到所有主题的...
VisendoSMTPExtender_Plus_x64.msi