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. 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. 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. Requirements and capabilities are a great mechanism for this, but you can't dynamically add capabilities. Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
