[
https://issues.apache.org/jira/browse/ARIES-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753548#comment-13753548
]
Stephan Siano commented on ARIES-1108:
--------------------------------------
>... I don't understand how Export-Service is working (but would like to)
>because it doesn't work for me.
> Presumably, something in your environment is parsing Export-Service and
> making the service capability available to the system.
Well Export-Service is actually not doing anything (except somehow declaring
that this bundle is supposed to provide this service...) This is also the case
in my equinox based environment.
I just had two implementations that were exporting a service, one DS based,
where the maven-bundle-plugin did not generate the Export-Service header and
one blueprint based one where it did. It didn't work with the first bundle but
it did work with the second, so I (wrongly) believed that the reason for that
was the Export-Service header, because both bundles registered the service in
the OSGi registry and I didn't expect the resolver to evaluate blueprint
service dependencies...
> Discuss a better user experience when dealing with service dependencies.
> ------------------------------------------------------------------------
>
> Key: ARIES-1108
> URL: https://issues.apache.org/jira/browse/ARIES-1108
> Project: Aries
> Issue Type: Brainstorming
> Components: Subsystem
> Reporter: John Ross
>
> Currently, Aries Subsystems will compute service requirements and
> capabilities for Blueprint bundles only. This can be particularly problematic
> for users with application subsystems having bundles with service
> dependencies on non-blueprint bundles outside of their control. For example,
> an application blueprint bundle with a service dependency on EventAdmin will
> fail to resolve unless the EventAdmin implementation bundle advertises the
> service capability in some supported way. To get around this, the user must
> either (1) turn the bundle into a blueprint bundle, (2) add a
> Provide-Capability header to the bundle's manifest, or (3) provide their own
> bundle with a Provide-Capability header advertising all of the services of
> interest.
> The following represents a non-exhaustive list of possibilities.
> (1) Engage bundle providers to include a Provide-Capability header
> advertising services. This would be particularly helpful for standard OSGi
> services. Engage OSGi to make this a requirement or best practice.
> (2) Update the maven bundle plugin to generate this header, as it currently
> does for the Export-Service header.
> (3) Support Import-Service and Export-Service headers in Aries Subsystems.
> These headers are already generated by the maven bundle plugin.
> (4) Support DS in Aries Subsystems.
> (5) Add some sort of service listener to Aries Subsystems that will ensure
> existing services are available as "virtual capabilities" to resolving
> subsystems.
> Note that in Aries Subsystems 1.0.1-SNAPSHOT+, the ModelledResourceManager
> service, used to compute service requirements and capabilities, is now
> optional. This means users can uninstall (or not install) the
> org.apache.aries.application.modeller bundle in order to disable service
> resolution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
