On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts <maili...@hupie.com> wrote: > > > On 07/10/16 21:04, Benson Margulies wrote: >> >> 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." > > > how about making the dependency: static + greedy + optional.
So, in practical terms, how greedy is 'greedy'? What's the behavior? > > that way your component will get started always, and restarted once X > becomes available. > >> >> 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 >> > > -- > Ferry Huberts > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev