Hi Guillaume. > I thought the generation of those headers had been removed since.
Is that to say that you're no longer using these headers? > What is the 'something better based on blueprint' you are talking about ? Emily Jiang's recent contributions under ARIES-361 include extensions to OBR that enable the OBRAriesResolver to provision against service dependencies inferred from individual bundles' <service> and <reference> blueprint elements. We don't yet have a standalone tool (like an extended bindex) that will produce the necessary repository.xml, but the code to do so can be found in the generateOBRRepoXML() method of OBRResolverAdvancedTest.java. Regards, Mark On 23 September 2010 13:51, Guillaume Nodet <[email protected]> wrote: > That was a long time ago. I thought the generation of those headers > had been removed since. > 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 >
