I am trying to express the following idea using DS: "If service X is provisioned in this container, do not activate me until it is activated and injected into me. If service X is not provisioned in this container, go ahead and activate me without it."
I fully appreciate that this concept is not compatible with the generally dynamic approach of OSGi in general, and declarative services in particular. However, I can think of a variation like: "I am willing to wait N seconds for service X. If it isn't there by then, activate me without it." I am taking a risk here -- it's always possible that some phenomenon would result in a delay of longer than N. But in my case, the startup properties of the containing application are such that this would be a low risk. Another possible approach would be to focus on provide/require capability. I don't know how I would get DS to pay attention, but it seems as if there's not enough information: Provide-Capability: osgi.service;objectClass:List<String>="com.basiste ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett eComponentService" Note that any properties are not represented here. So if the dependency is specific to some filter on properties, you can't use this data. At the extreme, I could take very close control of start order, and then go ahead and use optional references. That's a lot of start order management. Finally? I could use configuration admin, by setting the reference cardinality as part of provisioning. To do this cleanly, I think I'd want some sort of management layer that generated these 'minimum cardinality properties'; editing it in something like Karaf's cfg files would be quite messy. Is there something I'm missing? _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
