[
https://issues.apache.org/jira/browse/ARIES-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14739927#comment-14739927
]
John Ross commented on ARIES-1328:
----------------------------------
With regard to the original issue as stated in the description, what's missing
is something informing the subsystems implementation that a service dependency
exists. There are four ways this can currently be done.
(1) Define the service dependencies as part of a Blueprint XML file included in
the bundle.
(2) Declare a Require-Capability with the osgi.service namespace in the bundle
manifest.
(3) Create your own deployment manifest for the application.
(4) Use a composite.
With regard to (1) and (a), section 134.16.1 states "[An application] also does
not explicitly import any capabilities. Any required capabilities that are not
satisfied by the application's constituents are automatically shared in
(imported) from the parent Subsystem." Applications have their dependencies
computed for them. Requirement related headers are not valid if specified
within the subsystem manifest for applications. They should either be ignored,
or the application should fail installation. The specification is silent on
this. The Aries implementation ignores them.
With regard to (2) and (b), you indicate that what should work does in fact
work. That is, you added a content bundle declaring a service dependency via
the Require-Capability header to the application, you then ensured that a
matching capability was available, and the subsystem installed. Although the
Subsystem Service specification is silent on this, the Aries implementation
will consider both effective:=resolve and effective:=active as part of the
offline resolution at installation time; otherwise, it would be difficult to
include service dependencies since they will usually be effective:=active. Take
Blueprint for example. If you define a service capability for a bundle there,
it would be considered by Aries Subsystems but not by the framework. If you
then provided a bundle with a Require-Capability in the osgi.service namespace
and effective:=resolve, the framework would be unable to resolve that bundle
due to the unknown service capability. This would result in a subsystem start
failure because of an unsuccessful runtime resolution.
Assuming I've fully understood your situation, I don't see a bug to fix here.
> Application subsystem does not import services
> ----------------------------------------------
>
> Key: ARIES-1328
> URL: https://issues.apache.org/jira/browse/ARIES-1328
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
> Affects Versions: subsystem-core-1.2.0
> Reporter: David Bosschaert
> Attachments: api-bundle-1.0.0-SNAPSHOT.jar,
> application-subsystem-nosvc-1.0.0-SNAPSHOT.esa,
> application-subsystem-nosvc-rc.esa, application-subsystem-nosvc-ubrc.esa,
> svc-bundle2-1.0.0-SNAPSHOT.jar, use-bundle-1.0.0-SNAPSHOT.jar
>
>
> I have an application Subsystem that has a bundle that looks for a service
> via a service tracker.
> This service and its API is provided by pre-existing bundles (api-bundle,
> svc-bundle2) in the parent subsystem.
> The OSGi enterprise R5 spec states in 134.16.1 (Application Subsystems):
> "Any required capabilities that are not satisfied by the application's
> constituents are automatically shared in (imported) from the parent
> Subsystem."
> However when I install and start the application subsystem
> (application-subsystem-nosvc), it does not find the services provided in the
> parent.
> I'm attaching the bundles and subsystem to reproduce. The full source code
> can be found here: https://github.com/coderthoughts/subsystem-examples
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
