> 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] >
