On 10 Nov 2010, at 8:51 , Philipp Kursawe wrote: > 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).
The dynamics of OSGi services cannot be made "atomic", so in practice you: a) track services so you can stop using them when they go away b) always be prepared to get some kind of runtime exception when invoking a service method Greetings, Marcel _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
