[
https://issues.apache.org/jira/browse/ARIES-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946987#comment-14946987
]
David Bosschaert commented on ARIES-1398:
-----------------------------------------
Hi [~tjwatson],
> Are you suggesting we must have a mandatory, resolve type requirement for all
> services that are required for some bundle to be functional?
Well, yes, I think there is value in this. We expect bundles that resolve to be
functional. We have been introducing capabilities in Enterprise R6 to this
effect, such as {{osgi.extender}} and {{osgi.implementation}}. The same holds
for {{osgi.service}} capabilities. If a bundle only functions with a certain
service being present, this I think this would be a useful
{{osgi.service;effective:=resolve}} type requirement.
Not all osgi.cmpn specifications define the osgi.service capability just yet,
but most do and others are being updated for R7.
> Are you only suggesting that for this special case with the resolver package?
> If so, why?
No the resolver is not special, I think it should be done for all OSGi-spec
based services that are required.
> Surely other packages out of osgi.cmpn could cause similar issues with
> implementations of other services.
True, and that's why I think we should do this across the board for OSGi
spec-defined services.
Hi [[email protected]],
> If we go that route, the requirement should be optional
That doesn't work. Optional requirements are not enforced, the framework can do
whatever it wants with them, so they don't help in such a situation.
> Having said that, I still want to emphasize that the only motivating use case
> for this that I'm aware of is to allow people to install the R5 CMPN bundle
> into the runtime.
Unfortunately there are quite a lot of these deployed at runtime.
> 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)
