On Wed, Nov 18, 2015 at 7:38 AM, Neil Bartlett <[email protected]> wrote: > Fragments are not allowed to declare the Service-Component header (or > rather, if they do it will be ignored by SCR). It is however possible for > the DS XML and/or classes to be located in fragments, so long as the > Service-Component header is declared on the host bundle. So that may be one > route.
Right, that's the reading I did that caused me to conclude that I couldn't just trivially decorate classes in a fragment with DS annotations. I don't want the host to 'know' in advance the inventory of the fragments. > > Why not follow a composition approach rather than inheritance? You could > have a single aggregator component that is injected with all the various > services, and is then published as a service. Each of your smaller > components can then inject the aggregate service component. I more or less started with this, but the problem I had was deciding when all the services had arrived at the aggregator. I had to give the aggregator a property that told it how many services to expect, and this made me sad. I might be able to make the aggregator deal with them one-at-a-time instead of needing them all together, and then this would work tolerably well. Another line of thought I have involves letting them be fragments and then having the host collect them all and aggregate them. Is there a tasteful pattern for a host bundle to take note of its fragments, or is that inevitably ugly? > > Neil > > On Wed, Nov 18, 2015 at 12:23 PM, Benson Margulies <[email protected]> > wrote: > >> Thanks to all of you who educated me yesterday about DS annotation >> inheritance in bnd. I implemented it and it works very well. However, >> I have an incremental challenge. >> >> What I have here is a gaggle of web services. Most of the logic is >> common across them and lives in a base class, which now has @Reference >> injection to pick up things it needs from the larger environment, and >> activate/deactivate to manage lifecycle. >> >> However, I'd like to enable these services to come from disparate >> teams. Given the injunction to avoid cross-bundle inheritance of the >> DS annotations, I can't just export the package containing the base >> class from one bundle and then tell the teams to import and inherit. >> >> It only took about five minutes to think of the idea of putting each >> service in a fragment -- and then discard it, due to the fact that >> fragments can't carry DS metadata (according to Stack Overflow). >> >> Is there another trail to follow here, or is there just an inescapable >> dilemma between repeating DS annotations and decoupling the pieces? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
