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