You may want to refresh your memory about this very similar topic discussed in September of 2014:
https://mail.osgi.org/pipermail/osgi-dev/2014-September/004583.html - Ray On Thu, Nov 10, 2016 at 10:45 AM, <[email protected]> wrote: > Hi all, > > I totally agree that using a services-based approach is more elegant here. > > However in my use-case the bundles that should wait for the service may not > be developed with this condition in mind, so it's an extra condition that > should hold these bundles back. The bundles themselves could be written > using any technology, maybe with DS, maybe not (simple Bundle Activators). > > Maybe my idea isn't so generally useful after all, as services based > solutions - if you can use them - are certainly better. > > I guess I'll hold off contributing this. Thanks all for the feedback. > > Cheers, > > David > > On 10 November 2016 at 15:35, Neil Bartlett <[email protected]> wrote: > > > > > > On 10 Nov 2016, at 15:18, Carsten Ziegeler <[email protected]> > wrote: > > > > > > Neil Bartlett wrote > > >> I’m also somewhat opposed to David’s approach. I feel that it > conflates > > two separate concepts: bundles are for packaging and code delivery, this > > problem space is about enabling/disabling functionality based on > observable > > conditions. > > >> > > >> I would prefer to do this with Declarative Services. Rather than > > “holding back” an entire bundle, just do it with a DS component using a > > mandatory @Reference to a service. When the “external thing” happens, it > is > > detected and mapped to a published service. The availability of the > service > > allows the component’s @Reference to be satisfied and we are off to the > > races. This can also be easily understood and introspected at runtime > using > > the scr:list and scr:info commands, or the WebConsole with X-Ray. > > >> > > > > > > While the service approach is definitely working and a nice way as it > is > > > already available, I see a scalability problem. > > > > > > Think about use cases similar to the extender mechanism, you don't want > > > that your bundle starts until the DS extender is available. But you > > > don't want that each and every service has a reference to the DS > runtime > > > service. > > > > Why don’t I want my bundle to start until the DS extender is available? > It > > makes no difference. > > > > > > > > Let's assume you have an app, consisting of dozens of services, for > > > simplicity let's assume they are all in one bundle. Now you don't want > > > to start any of these services until some condition is met. > > > Clearly, you can add these special reference to each and every of the > > > dozen services, but that doesn't look nice to me. > > > > I don’t think it would work out that way in practice. Whatever this > > external condition is, would there really be dozens of components that > > refer to it *directly*? I think it’s more likely that a small number of > > low-level components would use that condition directly and offer services > > that are consumed by higher-level components. Thus the lifecycle of the > > higher-level components would still be contingent on the external > > condition, but indirectly. > > > > > > > > Then there is the problem if someone does not want to use DS (ok that's > > > their own problem maybe), or there is a bundle activator or something. > > > > > > In general, you simply don't want to start the app bundle at all. > > > > Then it seems we are talking past each other. I thought we were trying to > > find a good pattern for implementing this scenario, where functionality > > must be temporally dependent on an external condition. I still think this > > is best done in DS… but of course would be quite simple in Blueprint or > > DependencyManager or iPOJO, etc. Or even with the low-level APIs and > > ServiceTracker, if you happen to be a masochist. > > > > On the other hand you seem to be talking about poorly designed bundles > > that make assumptions about external conditions — and finding workarounds > > to allow those bundles to still work when the assumptions are > invalidated. > > If so then David’s proposal is valuable in that context. > > > > My problem is that in OSGi we are constantly fighting against bad > > practices and preconceptions. For example, every newbie always asks how > to > > achieve start ordering with the StartLevel service. We could just tell > them > > how to do it, or we can give them the understanding and techniques so > that > > start ordering becomes a non-issue. David’s proposal is a bit like Start > > Levels: I’m not saying it’s never necessary, but I wouldn’t want it to be > > misconstrued as good practice. > > > > Neil > > > > > > > > > > Requirements and capabilities are a great mechanism for this, but you > > > can't dynamically add capabilities. > > > > > > Carsten > > > > > > > > > > > > -- > > > Carsten Ziegeler > > > Adobe Research Switzerland > > > [email protected] > > > > > > > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
