Re: DS and .. Fragments (not)?
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. 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. 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 > >
DS and .. Fragments (not)?
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
Re: DS and .. Fragments (not)?
On Wed, Nov 18, 2015 at 7:38 AM, Neil Bartlett <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. > > 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 <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 For additional commands, e-mail: users-h...@felix.apache.org
Re: DS and .. Fragments (not)?
> 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. > > 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 <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>
Re: DS and .. Fragments (not)?
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
Re: DS and .. Fragments (not)?
On Wed, Nov 18, 2015 at 6:44 PM, Neil Bartlett <njbartl...@gmail.com> wrote: >> 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. Fragment should be avoided but just on the requirement of host to allow fragments to have DS components one can use a wildcard header Service-Component: OSGI-INF/*.xml In such a case would not any DS xml present in fragment bundle would get picked up? Chetan Mehrotra - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
