These deprecated headers were defined in the version 3 spec, section 4.14
4.14 Importing and Exporting Services
The Export-Service manifest header declares the interfaces that a bundle
may register. It provides advisory information that is not used by the
Frame-
work. This header is intended for use by server-side management tools.
The Export-Service manifest header must conform to the following syntax:
Export-Service ::= class-name ( ’,’ class-name )*
class-name ::= <fully qualified class name>
The Import-Service manifest header declares the interfaces the bundle may
use. It provides advisory information that is not used by the Framework.
This header is also intended for use by server-side management tools.
The Import-Service manifest header must conform to the following syntax:
Import-Service ::= class-name ( ’,’ class-name )*
class-name ::= <fully qualified class name>
As we discussed back on March 25 ("maven-bundle-plugin generating
Import-Service entries"), the maven bundle plugin is adding a lot of
non-compliant information, e.g.
Import-Service: org.apache.aries.blueprint.NamespaceHandler;filter="(o
sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/transac
tions/v1.0.0)",org.apache.aries.blueprint.NamespaceHandler;filter="(o
sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/jpa/v1.
0.0)"
Regards,
Mark
On 23 September 2010 14:41, Guillaume Nodet <[email protected]> wrote:
> The maven bundle plugin actaully check if the service is mandatory or
> not and should add that into the Import-Service manifest header.
> What exactly is not right with those headers ?
>
> On Thu, Sep 23, 2010 at 12: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
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
