On Wed, Nov 18, 2015 at 8:14 AM, Neil Bartlett <njbartl...@gmail.com> wrote: > >> On 18 Nov 2015, at 12:46, Benson Margulies <ben...@basistech.com> wrote: >> >> On Wed, Nov 18, 2015 at 7:38 AM, Neil Bartlett <njbartl...@gmail.com >> <mailto:njbartl...@gmail.com>> 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.
Mood swing humor aside, there might be 10 today, and 15 tomorrow. I prefer it to just self-organize. However, since I now think that I can make the aggregator deal with them one at a time, I can follow your general advice without any problem at all. > > >> >> 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… Something pretty unpleasant. I will stick to the aggregation pattern you suggested. > > >> >> >>> >>> Neil >>> >>> On Wed, Nov 18, 2015 at 12:23 PM, Benson Margulies <ben...@basistech.com> >>> 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: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> <mailto:users-unsubscr...@felix.apache.org> >> For additional commands, e-mail: users-h...@felix.apache.org >> <mailto:users-h...@felix.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
