On Thu, Sep 23, 2010 at 16:05, Timothy Ward <[email protected]> wrote: > > The headers are incorrect because they violate the syntax for Import-Service > and Export-Service. From the OSGi 3 specification: > > ----------------------------------------------------------------------------------------- > > 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 > Framework. > 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> > > ------------------------------------------------------------------------------------------ > > According to the specification it is not valid to supply any attributes or > directives, this means that anyone using this header may fail to process any > bundle which does. It also means that there's no standard way for anyone to > indicate service properties, filters or optionality. The fact that the bundle > plugin is doing this is actually causing bugs which we are having to work > around.
But since when is Aries supporting OSGi R3 ? We have requirements on OSGi R 4.2 afaik. This syntax specification comes from R3 and the R4 specs does not specify the syntax for those headers. I doubled checked a while back with osgi experts about that. Also if you have any tooling which supports OSGi R3 bundles, I must suppose it's a bit buggy because it's easy to check if a bundle is a R3 or R4 bundles by verifying if the Bundle-ManifestVersion is 2 or not. Those headers should be ignored for all R4 bundles. > If the bundle plugin needs to implement some custom function to support some > special use-cases in Felix then it should be using a custom manifest header, > and preferrably it should only add that header when configured to do so. > Right now anyone who uses the bundle plugin is, without their knowledge, > generating bundles that use an OSGi reserved header with syntax that violates > the core spec. Headers generated can always be removed in the bundle plugin by using the -removeheaders command for bnd. But I'd rather find another solution as I think this information is of real importance, especially in the generated OBR xml file. > Regards, > > Tim > > ---------------------------------------- >> Date: Thu, 23 Sep 2010 15:41:11 +0200 >> Subject: Re: Auto-generation of Import-Service and Export-Service >> From: [email protected] >> To: [email protected] >> >> 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 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
