I like this very much but I have a couple of questions. Am I understanding correctly that according to the proposal services must advertise which properties they wish to be aggregated? And that all properties from all services are aggregated into the same global list?
It would be more flexible imo if we could create instances of the aggregator through the config admin according to which services and properties we're interested in. The factory configuration could just be a service filter and a list of properties to aggregate from the matched services. This means we don't have to rely on them being marked for aggregation before hand, and also avoids clashes between unrelated services aggregating properties of the same name. On Mon, 24 Apr 2017 at 19:19 Peter Kriens <[email protected]> wrote: > There only needs to be a single implementation, it will learn its > properties from other services. If we standardize it then any developer can > leverage it. > > Kind regards, > > Peter Kriens > > > > > On 24 Apr 2017, at 19:12, Peter Kriens <[email protected]> wrote: > > I’ve written a blog about start ordering issues in OSGi and a potential > solution. This likely will interest many since it is a vexing OSGi problem. > > Feedback appreciated. > > http://aqute.biz/2017/04/24/aggregate-state.html > > Kind regards, > > Peter Kriens > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
