使用 Blueprint Container 规范构建 OSGi 应用程序Word格式文档下载.docx
《使用 Blueprint Container 规范构建 OSGi 应用程序Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《使用 Blueprint Container 规范构建 OSGi 应用程序Word格式文档下载.docx（25页珍藏版）》请在冰豆网上搜索。
Blueprint扩展器包还在包停止后为该包销毁BlueprintContainer。
本文将关注BlueprintXML。
通过若干示例展示组件XML定义及其使用。
BlueprintXML
BlueprintXML文件被标识为顶级blueprint元素，如清单1所示。
清单1.BlueprintXML文件片段
<
?
xmlversion="
1.0"
encoding="
UTF-8"
>
blueprintxmlns=”http:
//www.osgi.org/xmlns/blueprint/v1.0.0”>
...
/blueprint>
BlueprintXML文件包含各种组件管理器的定义。
BlueprintContainer规范定义了四种主要的组件管理器：
一个beanmanager、一个servicemanager和两个servicereferencemanagers。
每种管理器都负责创建和管理所创建组件的生命周期。
管理器提供了一个组件实例。
每个管理器都拥有相应的XML元素，用于描述管理器属性。
管理器可以是顶级管理器，或者内联在其他管理器定义内。
管理器还具有一些通用的属性。
id
定义管理器的ID。
id属性是可选属性。
如果没有指定的话，将自动生成一个唯一ID并分配给顶级管理器。
内联管理器被认为是匿名的，因此不允许设置id属性。
管理器ID在BlueprintContainer内对于所有顶级管理器必须是唯一的。
管理器使用ID彼此引用。
例如，在注入期间，管理器将要求被引用的管理器提供对象，该对象将被注入到管理器正在创建的组件中。
activation
这个可选属性为管理器定义激活模式。
可支持两种激活模式：
∙eager，其中管理器在BlueprintContainer初始化期间激活。
∙lazy，其中管理器按需要激活。
默认情况下，启用eager激活模式。
然而，通过对blueprint元素设置default-activation属性，可以为BlueprintXML文件内的所有管理器修改默认激活模式。
当要求管理器提供其第一个组件实例时，管理器将被激活。
当BlueprintContainer被销毁时，管理器将被解除激活。
每个管理器都拥有自己的激活和解除激活步骤。
dependsOn
这个可选属性指定了一个管理器ID列表。
所列出的管理器将在其他管理器之前激活。
管理器可以具有显式或隐式的依赖关系。
dependsOn属性定义了显式的依赖关系。
隐式依赖关系在管理器定义中通过对其他管理器的引用定义。
Bean管理器
bean管理器创建具有给定参数和属性的Java对象的实例。
bean管理器可以根据范围设置创建一个或多个对象实例。
它还可以管理对象的生命周期，并且在所有属性被注入或对象被销毁时通知对象。
在BlueprintXML中，bean元素将定义一个bean管理器。
用于对象构造的参数由argument元素指定；
注入的属性则由property子元素指定。
签名解析（disambiguation）
Blueprint规范定义了一个分多个步骤的算法，用于解析签名。
此算法考虑所有可能的构造函数以及每个构造函数中的参数组合，从而找到最佳匹配。
相同的算法被用于方法中。
规范的121.9.1小节介绍了详细内容。
在对象构造期间，BlueprintContainer必须首先找到合适的构造函数或工厂方法，这个构造函数或工厂方法具有一组类似的参数，这些参数与XML中指定的参数匹配。
默认情况下，BlueprintContainer使用XML中的argument元素的数量和顺序查找匹配的构造函数或方法。
如果argument元素无法根据自身的排列顺序映射到参数，那么BlueprintContainer将尝试重新对argument属性排序并查找最匹配的组合。
为了帮助BlueprintContainer选择合适的构造函数、方法或参数组合，可以在argument元素中指定额外的属性，例如index或type。
例如，type指定了一个列名，用于根据精确的类型将argument元素匹配到参数。
property元素指定要注入的属性的名称和值。
属性名与Java类中的setter方法名对应。
例如，如果属性名为foo，那么对应的setter方法为setFoo（arg）。
属性名和对应的setter方法名遵循JavaBeans规范中定义的属性设计模式。
argument和property元素的值可以通过value或ref属性指定，或者可以被内联。
ref属性指定顶级管理器的ID，并用于从引用管理器获得对象，作为参数或属性值。
内联的值可以为“Objectvalues”小节中描述的任意XML值。
构建
bean可以通过以下内容以三种方式构建：
∙一个类构造函数
∙一个静态工厂方法
∙一个实例工厂方法
清单2、3和4演示了三种构建Java对象的方法。
每一个清单展示一个不完整的Java类以及用于驱动对象创建的相应的BlueprintXML片段。
清单2展示了一个简单的构造器创建示例。
在这个例子中，class属性指定将要实例化的Java类的名称。
BlueprintContainer将创建Account对象，方式为将1作为参数传递给构造器并调用setDescription（）方法注入描述属性。
清单2.构造器示例
publicclassAccount{
publicAccount（longnumber）{
}
publicvoidsetDescription（Stringdescription）{
publicStringgetDescription（）{
<
beanid=”accountOne”class=“org.apache.geronimo.osgi.Account”>
argumentvalue=”1”/>
propertyname=”description”value=”#1account”/>
/bean>
清单3展示了一个静态的工厂方法构造。
在这个例子中，class属性指定了包含静态工厂方法的类的名称。
这个静态工厂方法的名称由factory-method属性指定。
BlueprintContainer将对AccountFactory类调用createAccount（）静态方法并将2作为参数传递，用于创建Account对象。
当工厂返回创建的对象后，容器将向它注入描述属性。
清单3.静态工厂方法示例
publicclassStaticAccountFactory{
publicstaticAccountcreateAccount（longnumber）{
returnnewAccount（number）;
beanid=”accountTwo”class=“org.apache.geronimo.osgi.StaticAccountFactory”
factory-method=“createAccount”>
argumentvalue=”2”/>
propertyname=”description”value=”#2account”/>
对于实例工厂方法构建，如清单4所示，使用了两个管理器。
其中一个管理器是工厂，另一个管理器使用该工厂创建对象。
factory-ref用来指定顶级bean的ID或行为类似工厂的引用管理器。
提供的工厂对象必须具有一个由factory-method属性指定的工厂方法。
在本例中，accountFactorybean管理器是一个工厂。
BlueprintContainer将首先创建AccountFactory实例，该实例具有自己的参数和属性。
在本例中，只指定了一个参数：
工厂名。
BlueprintContainer随后将对AccountFactory实例调用createAccount（）方法，然后将3作为参数传递，以创建Account对象。
一旦工厂返回创建的对象，容器将向其注入描述属性。
清单4.实例工厂方法示例
publicclassAccountFactory{
publicAccountFactory（StringfactoryName）{
publicAccountcreateAccount（longnumber）{
beanid=”accountFactory”class=“org.apache.geronimo.osgi.AccountFactory”>
argumentvalue=”accountfactory”/>
beanid=”accountThree”
factory-ref=“accountFactory”
argumentvalue=”3”/>
propertyname=”description”value=”#3account”/>
范围
根据范围设置，一个bean管理器可以创建一个或多个对象实例。
BlueprintContainer规范指定了两个主要的范围：
singleton
bean管理器创建了bean的单个实例，并在每次要求管理器提供对象时返回该实例。
prototype
bean管理器在每次要求管理器提供对象时都将创建一个bean的新实例。
默认情况下，singleton范围被应用于顶级bean管理器。
scope属性不能在内联bean管理器中设置，因此内联管理器总是被认为具有prototype范围。
scope属性用于指定范围设置。
清单5展示了两个具有不同范围设置的bean定义。
清单5.范围示例
beanid=”prototypeAccount”class=“org.apache.geronimo.osgi.Account”
scope=”prototype”>
argumentvalue=”4”/>
beanid=”singletonAccount”class=“org.apache.geronimo.osgi.Account”
scope=”singleton”>
argumentvalue=”5”/>
生命周期回调
bean管理器还可以管理它所创建的对象的生命周期，并在所有属性被注入或对象被销毁时通知对象。
BlueprintContainer规范指定了两种回调方法：
init-method
指定了一种方法，该方法在所有属性被注入时将得到调用。
destroy-method
指定了一种方法，该方法在BlueprintContainer销毁对象实例时得到调用。
destroy-method回调在prototype范围中不受bean支持。
由应用程序负责销毁这些实例。
所有生命周期方法都必须是公共的，不包含任何参数，并且不返回值。
清单6展示了一个Java类的实例，它具有生命周期方法和一个BlueprintXMLbean条目，后者指定了init-method和destroy-method属性。
清单6.生命周期回调示例
publicvoidinit（）{
publicvoiddestroy（）{
beanid=”accountFour”class=“org.apache.geronimo.osgi.Account”
init-method=”init”destroy-method=”destroy”>
argumentvalue=”6”/>
propertyname=”description”value=”#6account”/>
服务引用管理器
服务引用管理器提供了对OSGi服务注册表中已注册服务的访问。
Blueprint规范定义了两种服务引用管理器：
引用（reference）和引用列表（referencelist）管理器。
引用管理器
引用管理器提供了一个对象，该对象充当在服务注册表中注册了的实际服务的代理。
代理允许被注入的对象保持不变，同时后端服务可以变化或被其他服务取代。
对不具备后端服务的代理的调用将被阻塞，直到服务变得可用或发生超时。
引用管理器由reference元素定义。
代理用于等待后端服务变为可用的时间的长度将由timeout属性指定。
如果timeout属性没有被指定，那么默认的超时值为5分钟。
也可以为BlueprintXML文件中的所有引用管理器修改默认超时，只需要修改blueprint元素的default-timeout属性。
所有超时值都以毫秒为单位指定；
值为0则表示无限期超时。
清单7展示了一个简单的引用管理器示例。
服务代理将拥有一个30秒的超时。
清单7.引用管理器示例
referenceid=”serviceReferenceOne”
interface=”java.io.Serializable”
timeout=”30000”/>
引用列表管理器
引用列表管理器提供了一个List对象，其中包含服务代理对象或ServiceReference对象，具体取决于成员类型设置。
提供的List对象是动态的，因为随着匹配服务被添加到服务注册表或从中移除，该对象可以增加或缩小。
List对象是只读的并且只支持一部分ListAPI。
引用列表管理器中的代理不同于引用管理器中的代理。
它们使用固定的后端服务，不存在超时，并且如果后端服务变得不可用，将立即抛出ServiceUnavailableException。
引用列表管理器由reference-list元素定义。
提供的List对象的成员类型由member-type属性指定。
member-type属性支持两种值：
service-object
注入一个服务代理对象列表，被认为是默认值。
service-reference
注入一个ServiceReference对象列表。
清单8展示了一个简单的引用列表管理器示例。
List成员为服务代理。
清单8.引用列表管理器示例
reference-listid=”serviceReferenceListOne”
member-type=”service-object”/>
服务选择和代理
引用和引用列表管理器具有一些相同的属性。
三个相同的属性用于服务选择：
interface、component-name和filter。
可以使用interface属性指定一个接口类。
这个接口类用于两个目的：
用于服务选择和服务代理。
interface属性是可选的，但是如果设置了该属性，那么它必须指定一个接口类。
对于服务选择，接口类被用于从服务注册表（使用该接口名注册）中选择服务。
对于服务代理，服务引用管理器返回的代理必须实现由接口类定义的所有方法。
如果接口属性未被指定，那么代理的行为就类似于实现一个不包含任何方法的接口。
还可以将component-name和filter属性用于服务选择。
component-name是一种将pname=<
component-name>
表达式添加到选择过滤器的方便方法。
类似地，filter属性指定将被添加到选择过滤器的原始OSGi过滤器表达式。
interface、component-name和filter属性被结合在一起，创建一个用于服务选择的主要的OSGi过滤器表达式。
例如，清单7中的引用的选择过滤器为（&
（objectClass=java.io.Serializable）），而清单9中的引用的选择过滤器为（&
（objectClass=java.io.Serializable）（pname=myAccount）（mode=shared））。
清单9.服务选择示例
referenceid=”serviceReferenceTwo”
component-name=”myAccount”
filter=”（mode=shared）”/>
可用性
在BlueprintContainer继续进行初始化之前，服务引用管理器需要至少一个服务匹配其选择条件。
这一要求是由availability属性控制的。
availability属性可以有两个值：
optional
匹配选择条件的服务可能存在，也可能不存在。
mandatory
至少存在一个匹配选择条件的服务。
默认情况下，假定使用mandatory可用性。
通过使用blueprint元素的default-availability属性，可以为BlueprintXML中的所有服务引用管理器修改默认可用性设置。
具有mandatory可用性的服务引用管理器（具有一个匹配服务）被认为是可以满足需求的。
具有optional可用性的服务引用管理器总是被认为可以满足需求，即使它不具备任何匹配的服务。
BlueprintContainer初始化将被延迟，除非所有强制服务引用管理器都得到满足。
必须要注意的一点是，只有在BlueprintContainer初始化期间才考虑mandatory可用性。
完成初始化后，随着服务在任意时刻的变化，强制服务引用将不能被满足。
清单10展示了一个具有mandatory可用性的引用管理器的示例。
清单10.可用性示例
referenceid=”serviceReferenceThree”
timeout=”30000”
availability=”mandatory”/>
引用侦听器
所有服务引用管理器都可以具有0个或多个引用侦听器。
引用侦听器指这样一些对象：
当服务引用管理器选择了服务或当服务引用管理器不再使用服务时，调用回调方法。
引用侦听器使用reference-listener元素指定。
bind-method和unbind-method属性指定回调方法。
提供回调方法的对象可以内联到reference-listener元素内，或指定为对顶级管理器的引用。
绑定回调或非绑定回调都可以拥有以下任意签名（anyMethod表示一个任意的方法名）。
voidanyMethod（ServiceReference）
该参数为被绑定或解除绑定的服务的ServiceReference对象。
voidanyMethod（?
superT）
该参数是被绑定或解除绑定的服务对象代理。
服务对象必须能够指定类型T。
voida
升级会员 