Import-Service and subsystems

["Siano, Stephan" <st...@sap.com>]

Hi,

I have trouble with Import-Service manifest headers in bundles that are contained in a subsystem. If there is an Export-Service manifest header (in the subsystem or outside) everything is fine, however if there is no such header, installation of the subsystem fails because the dependency cannot be resolved.

Is this intentional? The OSGi 5.0 core spec says about these headers that they are deprecated and for informational purposes only, but the maven bundle plugin generates them for exposed blueprint services. The resolver and subsystem specifications don't say anything about this, so I am not really sure where to fix it (in the resolver or in the Subsystem implementation (if I had to guess, it might be somewhere with the SubsystemResource class).

Best regards
Stephan

RE: Import-Service and subsystems

[John W Ross <jw...@us.ibm.com>]

Support for service requirements and capabilities is built into the
Subsystems spec via the Subsystem-ImportService and Subsystem-ExportService
headers. The grey area is in how they are computed for application
subsystems because there is no standard provided. It is left up to the
implementation. Aries Blueprint was, of course, a natural fit for Aries
Subsystems and is currently the only way to have service requirements and
capabilities computed in Aries. It would be possible to add support for
additional mechanisms. DS would be an obvious example. It would also be
possible to support the deprecated Import-Service and Export-Service
headers, although that might be more controversial.

For now, I suggest that you install a bundle at the framework level (i.e.
the root subsystem) with a manifest having a Provide-Capability header
describing all of the services you know will be there. For example,
Provide-Capability:
osgi.service;objectClass=org.osgi.service.event.EventAdmin. You could also
update the manifests of the service providing bundles directly.
Alternatively, if you're using the 1.0.1-SNAPSHOT version of subsystems,
you could uninstall the optional org.apache.aries.application.modeller
bundle which means service requirements and capabilities will not be
computed.

John

>
> RE: Import-Service and subsystems
>
> Hi John,
>
> Ok, I see. So my assumption that the service requirement is coming
> from the manifest is wrong (and it is coming from the blueprint
> descriptor). However, this does not seem to work if a service
> required by a blueprint bundle is not provided by another blueprint
> bundle (but by other means). In my example it’s equinox’ event admin
> service. Is this really the intended behavior of the subsystem
> implementation? From my understanding the subsystem implementation
> should ignore service requirements and capabilities. I have tried to
> debug this, but I actually didn’t manage to really understand the
> interactions between the resolver and the ModelledResourceManager.
>
> For the one example that I “fixed”: I changed one bundle providing a
> service from DS to blueprint. That did also create an Export-Service
> manifest header (but as I learned now the true reason why it worked
> afterwards was the blueprint descriptor).
>
> Best regards
> Stephan
>
> From: John W Ross [mailto:jwross@us.ibm.com]
> Sent: Dienstag, 27. August 2013 15:28
> To: user@aries.apache.org
> Subject: Re: Import-Service and subsystems
>
> Aries Subsystems does not pay attention to either the Import-Service
> or Export-Service bundle manifest headers. They are not used to
> compute the service requirements or capabilities of bundles or
> subsystems. However, if the ModelledResourceManager service is
> present, service requirements and capabilities are computed using
> Blueprint. This is where your requirements are coming from. The fact
> that the maven bundle plugin generates Import-Service headers is
incidental.
>
> I can't explain why adding the Export-Service header works other
> than simply stating that something outside of subsystems must be
> making it available as a service capability. For Aries Subsystems, a
> matching capability would typically be provided by Blueprint.
>
> John
>
> >
> > Import-Service and subsystems
> >
> > Hi,
> >
> > I have trouble with Import-Service manifest headers in bundles that
> > are contained in a subsystem. If there is an Export-Service manifest
> > header (in the subsystem or outside) everything is fine, however if
> > there is no such header, installation of the subsystem fails because
> > the dependency cannot be resolved.
> >
> > Is this intentional? The OSGi 5.0 core spec says about these headers
> > that they are deprecated and for informational purposes only, but
> > the maven bundle plugin generates them for exposed blueprint
> > services. The resolver and subsystem specifications don’t say
> > anything about this, so I am not really sure where to fix it (in the
> > resolver or in the Subsystem implementation (if I had to guess, it
> > might be somewhere with the SubsystemResource class).
> >
> > Best regards
> > Stephan

RE: Import-Service and subsystems

["Siano, Stephan" <st...@sap.com>]

Hi John,

Ok, I see. So my assumption that the service requirement is coming from the manifest is wrong (and it is coming from the blueprint descriptor). However, this does not seem to work if a service required by a blueprint bundle is not provided by another blueprint bundle (but by other means). In my example it’s equinox’ event admin service. Is this really the intended behavior of the subsystem implementation? From my understanding the subsystem implementation should ignore service requirements and capabilities. I have tried to debug this, but I actually didn’t manage to really understand the interactions between the resolver and the ModelledResourceManager.

For the one example that I “fixed”: I changed one bundle providing a service from DS to blueprint. That did also create an Export-Service manifest header (but as I learned now the true reason why it worked afterwards was the blueprint descriptor).

Best regards
Stephan

From: John W Ross [mailto:jwross@us.ibm.com]
Sent: Dienstag, 27. August 2013 15:28
To: user@aries.apache.org
Subject: Re: Import-Service and subsystems


Aries Subsystems does not pay attention to either the Import-Service or Export-Service bundle manifest headers. They are not used to compute the service requirements or capabilities of bundles or subsystems. However, if the ModelledResourceManager service is present, service requirements and capabilities are computed using Blueprint. This is where your requirements are coming from. The fact that the maven bundle plugin generates Import-Service headers is incidental.

I can't explain why adding the Export-Service header works other than simply stating that something outside of subsystems must be making it available as a service capability. For Aries Subsystems, a matching capability would typically be provided by Blueprint.

John

>
> Import-Service and subsystems
>
> Hi,
>
> I have trouble with Import-Service manifest headers in bundles that
> are contained in a subsystem. If there is an Export-Service manifest
> header (in the subsystem or outside) everything is fine, however if
> there is no such header, installation of the subsystem fails because
> the dependency cannot be resolved.
>
> Is this intentional? The OSGi 5.0 core spec says about these headers
> that they are deprecated and for informational purposes only, but
> the maven bundle plugin generates them for exposed blueprint
> services. The resolver and subsystem specifications don’t say
> anything about this, so I am not really sure where to fix it (in the
> resolver or in the Subsystem implementation (if I had to guess, it
> might be somewhere with the SubsystemResource class).
>
> Best regards
> Stephan

Re: Import-Service and subsystems

[John W Ross <jw...@us.ibm.com>]

Aries Subsystems does not pay attention to either the Import-Service or
Export-Service bundle manifest headers. They are not used to compute the
service requirements or capabilities of bundles or subsystems. However, if
the ModelledResourceManager service is present, service requirements and
capabilities are computed using Blueprint. This is where your requirements
are coming from. The fact that the maven bundle plugin generates
Import-Service headers is incidental.

I can't explain why adding the Export-Service header works other than
simply stating that something outside of subsystems must be making it
available as a service capability. For Aries Subsystems, a matching
capability would typically be provided by Blueprint.

John

>
> Import-Service and subsystems
>
> Hi,
>
> I have trouble with Import-Service manifest headers in bundles that
> are contained in a subsystem. If there is an Export-Service manifest
> header (in the subsystem or outside) everything is fine, however if
> there is no such header, installation of the subsystem fails because
> the dependency cannot be resolved.
>
> Is this intentional? The OSGi 5.0 core spec says about these headers
> that they are deprecated and for informational purposes only, but
> the maven bundle plugin generates them for exposed blueprint
> services. The resolver and subsystem specifications don’t say
> anything about this, so I am not really sure where to fix it (in the
> resolver or in the Subsystem implementation (if I had to guess, it
> might be somewhere with the SubsystemResource class).
>
> Best regards
> Stephan