我们一直在努力让SPI Fly与 openstack4j-core 以及openstack4j连接器之一（ openstack4j-httpclient ）配合使用。 org.openstack4j.core.transport.HttpExecutorService需要SPIFly编织。
一个怪癖：两个捆绑包都是从zip文件加载的，并在系统的其余部分启动并运行后启动。相同的zip文件提供org.apache.aries.spifly.dynamic.bundle。
这两个捆绑包使用the standard set of instructions for 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 在 META-INF / services 下有一个名为org.openstack4j.core.transport.HttpExecutorService的文件，其中包含以下单行：
org.openstack4j.connectors.httpclient.HttpExecutorServiceImpl
我们还添加org.apache.aries.spifly.dynamic.bundle捆绑包，该捆绑包提供serviceloader.processor和serviceloader.registrar功能。
然后在运行时，ServiceLoader调用找不到HttpExecutorService。
PS：弄乱捆绑包的启动顺序并不富有成效，并且在启动所有捆绑包之前在resolveBundles上调用FrameworkWiring无效。