> On 18 Nov 2015, at 12:46, Benson Margulies <[email protected]> wrote: > > On Wed, Nov 18, 2015 at 7:38 AM, Neil Bartlett <[email protected] > <mailto:[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.
Right, this is certainly a limitation. Also you really don’t want to use fragments if you can avoid it. > >> >> 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. Notwithstanding your mood swings, what is wrong with setting the service references to mandatory (which is the default anyway)? Then the aggregator component will not be published until the references are satisfied. > > 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? Given your BundleWiring instance, you can find all the wires provided by your bundle in the ‘osgi.wiring.host' namespace (HostNamespace.HOST_NAMESPACE) and following them through to their requirers. But I’m not sure what you are planning to do next with this information… > > >> >> 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] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]>
