On 11/10/2010 5:23 AM, Peter Lauri wrote:
Hi,
We have developed a few OSGI components that are publishing/consuming services.
However, we have one issue that we don't know the best design of.
Bundle A is consuming a service that Bundle B is providing. The service of B
depends on configurations in a directory (xml files) and will be registered when
it gets a ManagedService.updated call. Assume we reconfigure the system, that
means new xml/modified files ends up in the directory and we manually refresh the
configuration bundle => ManagedService.updated is called. Meanwhile this
configuration changes are read up, the service should not be usable. So there are
two possibilities as I see it (or are there more?):
Option A: We keep the service registration, but make sure that calls to the
service cannot be performed meanwhile configurations are read up (internal
synchronization).
Option B: We unregister the service, read configuration, register the service
again. The consumer then need to track this removedService it self.
What is the best pattern here? Any general recommendations? Is there any good
Option C?
/Peter
Excuse me when I hijack your thread, Peter I have a similar question to
add here:
What if consumer A uses Service B and this service unregisters but A
still holds a (java) reference to that service and continues to use it.
That would work, however B could have an internal state (after
unregistering it) that would not allow it to be used anymore. So
basically A is a "bad citizen" in the OSGi world, isn't he? Consumers
*always* need to check if their service is gone and do proper thread
synchronization when accessing their service reference (AtomicReference).
Phil
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
