According to that other thread, the proposed solution would also require that the framework have:
>>> Provide-Capability: osgi.service; >>> osgi.service=org.osgi.service.resolver.Resolver; >>> uses:=org.osgi.service.resolver Is that the case here? Also, let's remember that this was caused by installing the resolvable R5 cmpn bundle into the runtime which exports the service package but does not actually register a service. Are there any other more practical scenarios that would make this a worthwhile endeavour? I'm not sure we want a solution that would always wire subsystems to the framework resolver. Folks may wish to use another. On Wed, Oct 7, 2015 at 4:24 AM, David Bosschaert (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/ARIES-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946581#comment-14946581 > ] > > David Bosschaert commented on ARIES-1398: > ----------------------------------------- > > I've reopened this issue now that the conclusion in FELIX-5049 is that this > is not a problem with the framework. > > The Aries Subsystem implementation could be amended to include > Require-Capability on the osgi.service capabilities for those services > without which it does not function - that should resolve this issue too. Is > this something to consider? These would have to be resolve-time requirements > for those mandatory services... > >> Aries Subsystem implementation is start-order dependent >> ------------------------------------------------------- >> >> Key: ARIES-1398 >> URL: https://issues.apache.org/jira/browse/ARIES-1398 >> Project: Aries >> Issue Type: Bug >> Components: Subsystem >> Affects Versions: subsystem-2.0.2 >> Reporter: David Bosschaert >> Attachments: nowork.txt, services.txt, works.txt >> >> >> From an email thread by Paul F Frazer: >> https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser >> When the Aries Subsystem implementation is started in a certain order the >> synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not >> created. >> While the original bug was reported on the Raspberry Pi, this can also be >> reproduced on an ordinary laptop. For example by starting the bundles in the >> following order: >> {code}START LEVEL 1 >> ID|State |Level|Name >> 0|Active | 0|System Bundle (5.2.0) >> 1|Active | 1|Apache Felix Bundle Repository (2.0.4) >> 2|Active | 1|Apache Felix Gogo Command (0.14.0) >> 3|Active | 1|Apache Felix Gogo Runtime (0.16.2) >> 4|Active | 1|Apache Felix Gogo Shell (0.10.0) >> 5|Active | 1|Apache Felix Configuration Admin Service (1.8.6) >> 6|Active | 1|Apache Felix Coordinator Service (1.0.0) >> 7|Active | 1|osgi.cmpn (5.0.0.201305092017) >> 8|Active | 1|slf4j-api (1.7.12) >> 9|Active | 1|Region Digraph (1.1.0.v20120522-1841) >> 10|Active | 1|Apache Aries Subsystem Core (2.0.2) >> 11|Resolved | 1|slf4j-simple (1.7.12) >> 12|Active | 1|Apache Aries Util (1.1.1) >> 13|Active | 1|Apache Aries Subsystem API (2.0.2) >> {code} >> As you can see the synthesized bundle does not appear. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332)
