[
https://issues.apache.org/jira/browse/ARIES-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14900567#comment-14900567
]
John Ross commented on ARIES-1404:
----------------------------------
I assume you're using the Application-ImportService header because of the
ARIES-1357 comment [1] in which I pointed out that the Subsystem-ImportService
header is computed for applications and may not be overridden? I want to be
sure you understand the following about the Application-ImportService header
introduced in ARIES-997:
(1) It is a non-standard, implementation specific application header introduced
for a very specific use case, namely one in which the subsystems provider does
not wish the subsystem to fail to install due to missing service dependencies
that will be made available to the application via some unknown (to the
implementation) means outside of the subsystems specification. The motivating
use case here was SCA [2]. I want to emphasize that the service imports are
*not* added to the import sharing policy. You are completely responsible for
somehow making those services available to the subsystem. In SCA, for example,
this might be done via injection.
(2) It is not a substitute for the Subsystem-ImportService header. I suspect
your motivation here is that you are not using Blueprint and need some way to
tell the implementation about your service dependencies, and since you can't
use the Subsystem-ImportService header for applications, you're looking around
for something else. If my suspicion is correct, I suggest that the best way to
go about this without using Blueprint would be to use the Require-Capability
header with the osgi.service namespace in one or more bundles.
[1]
https://issues.apache.org/jira/browse/ARIES-1357?focusedCommentId=14804376&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14804376
[2] https://en.wikipedia.org/wiki/Service_Component_Architecture
> Restart of the osgi container does not restart subsystem core because of an
> error related to missing resource
> org.apache.aries.subsystem.resource.synthesized
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ARIES-1404
> URL: https://issues.apache.org/jira/browse/ARIES-1404
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
> Affects Versions: subsystem-2.0.3
> Environment: On karaf 4 with subsystem-2.0.3-SNAPSHOT revision 1702099
> Reporter: Bas
> Labels: patch
> Attachments: ProvisionResourceSynthesized.patch,
> provision-resource-synth.zip
>
>
> Restart of the osgi container does not restart subsystem core because of an
> error related to missing resource
> org.apache.aries.subsystem.resource.synthesized
> The deployment manifest contains the entry below in the provision-resource
> header:
> org.apache.aries.subsystem.resource.synthesized;resourceId=-1;deployed-version=0.0.0;type=org.apache.aries.subsystem.resource.synthesized
> On restart it tries to load the resource because it is in the deployment
> manifest and can't find the resource in the osgi framework.
> It seems the 'synthesized' type is related to something which looks like a
> missing capability/service capability placeholder while installing/resolving.
> It is not installed because the ResourceInstaller has an if statement
> returning an installer which does nothing. So I guess it should also not be
> added to the manifest.
> I therefore patched the ProvisionResourceHeader to check for this
> 'synthesized' type and ignore it for the Provision-resource header. I'm not
> sure if this is the best solution but it does solve the issue we are having.
> The reason for patching it there is because it would be least affecting the
> entire process. Just like ignoring it before it is installed in the osgi
> framework it will not also be ignored before adding it to the manifest.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
