An exported service may depend, either directly or indirectly,
on other services in order to perform its function. If one of these
services is considered a mandatory dependency
(has cardinality 1..x
) and the
dependency can no longer be satisfied
(because the backing service has gone away and there is no suitable
replacement available) then the exported service that depends on it
will be automatically unregistered from the service registry - meaning
that it is no longer available to clients. If the mandatory dependency
becomes satisfied once more (by registration of a suitable service),
then the exported service will be re-registered in the service
registry.
This automatic unregistering and re-registering of exported
services based on the availability of mandatory dependencies only
takes into account declarative dependencies. If exported service
S
depends on bean A
, which in
turn depends on mandatory imported service M
, and
these dependencies are explicit in the Spring configuration file as
per the example below, then when M
becomes
unsatisfied S
will be unregistered. When
M
becomes satisfied again, S
will be re-registered.
<osgi:service id="S" ref="A" interface="SomeInterface"/> <bean id="A" class="SomeImplementation"> <property name="helperService" ref="M"/> </bean> <!-- the reference element is used to refer to a service in the service registry --> <osgi:reference id="M" interface="HelperService" cardinality="1..1"/>
If however the dependency from A
on
M
is not established through configuration as shown
above, but instead at runtime through for example passing a reference
to M
to A
without any
involvement from the Spring container, then Spring Dynamic Modules
will not track this dependency.