On Thu, Sep 23, 2010 at 14:51, Guillaume Nodet <[email protected]> wrote: > That was a long time ago. I thought the generation of those headers > had been removed since.
I was wrong, I was thinking about the additional package / service imports generated for blueprint custom namespace handlers. > Maybe it has only been removed for some maven modules and not in all places > ... > > What is the 'something better based on blueprint' you are talking about ? > > On Thu, Sep 23, 2010 at 13:07, Mark Nuttall <[email protected]> wrote: >> 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 >>> >> > > > > -- > 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
