We talked about this previously back in February in the thread 'Re: [jira]
Resolved: (ARIES-197) Fix the Export-Service / Import-Service headers.'
Guillaume wrote,
I do agree those headers are mostly useful for the OBR capabilities
generation.
I'd be more than happy to remove them once we have something better based on
blueprint.
In the mean time, I think it's quite harmless to keep them in. They really
help when generating OBR requirements, so that in Karaf, i can simply write
the following command:
obr:start "Apache Aries Application Management"
I think it's time to take these headers out. We do now have something better
based on blueprint. The headers are not harmless since the service-based
provisioning code parses them. They contain non-standard values which we
cannot be certain to parse correctly in all cases.
Regards,
Mark
On 23 September 2010 11:29, Timothy Ward <[email protected]> wrote:
>
> Hi,
>
> There are some problems with the way in which Aries models bundles for
> resolution in OBR. Currently we look at the blueprint for imported and
> exported services, but also fall back to the Import-Service and
> Export-Service headers in case there are any legacy bundles.
>
> Unfortunately it seems as though all of our bundles have Import-Service and
> Export-Service headers generated (using non-standard directives and
> attributes to boot). This means that we duplicate service imports and
> exports in our OBR model, which is a major performance concern, but worse,
> the headers are interpreted differently.
>
> ARIES-425 was caused by the fact that the duplicate Import-Service header
> caused an optional blueprint service to also be found as a mandatory
> Import-Service. Where are these non-standard, deprecated headers coming from
> and how can we turn them off?
>
> Regards,
>
> Tim
>
