Joz*_*zin 6 java apache osgi serviceloader
我们一直在努力让SPI Fly与openstack4j-core和openstack4j连接器之一(openstack4j-httpclient)配合使用.这org.openstack4j.core.transport.HttpExecutorService需要SPIFly编织.
一个怪癖:两个捆绑包都是从一个zip文件加载的,并在系统的其余部分启动并运行后启动.相同的zip文件提供了org.apache.aries.spifly.dynamic.bundle.
这两个捆绑包使用SPI Fly的标准指令集中的OSGI-Spec兼容模型.根据这些说明,我们真正需要的是两个包的MANIFEST.MF中的相应Require-Capability和Provide-Capability标题,在META-INF /下面显示服务声明(如下所示).
核心包有:
Require-Capability: 
osgi.serviceloader;filter:="(osgi.serviceloader=org.openstack4j.api.APIProvider)";cardinality:=multiple,
osgi.serviceloader;filter:="(osgi.serviceloader=org.openstack4j.core.transport.HttpExecutorService)";cardinality:=multiple,
osgi.serviceloader;filter:="(osgi.serviceloader=org.openstack4j.openstack.logging.LoggerFactorySupplier)";cardinality:=multiple;resolution:=optional,
osgi.extender;filter:="(osgi.extender=osgi.serviceloader.processor)",
osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)",
osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
httpclient有一个:
Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
Provide-Capability: osgi.serviceloader;osgi.serviceloader="org.openstack4j.core.transport.HttpExecutorService"
(当然,为了可读性而重新格式化)
此外,   openstack4j-HttpClient的有命名的文件org.openstack4j.core.transport.HttpExecutorService下META-INF /服务,用一行:
org.openstack4j.connectors.httpclient.HttpExecutorServiceImpl
我们还添加了org.apache.aries.spifly.dynamic.bundle包,它提供了serviceloader.processor和serviceloader.registrar能力.
然后在运行时,ServiceLoader调用只是找不到HttpExecutorService.
PS:与秩序搞乱,其中束开始一直没有卓有成效的,并呼吁resolveBundles在FrameworkWiring之前发表的所有捆没有奏效.
| 归档时间: | 
 | 
| 查看次数: | 336 次 | 
| 最近记录: |