Whenever you hold a reference to some other object you run a risk that that object will enter a state in which some method you invoke will not do what you would like. Maybe it lost connectivity with a database or a web service on which it relies, maybe it is recovering from some error condition in an algorithm or performing a roll-back of some kind, who knows. Maybe it will throw an IllegalStateException, maybe it will just fail silently or return null which it normally never does. Most of the time most developers live with these theoretical risks without even being aware of them.
Services in OSGi bring these concerns into the open and indicate where you need to pay attention. It actually gives a component a way to signal to the rest of the system that it is having a bad hair day, is that cool or what? If you use DS you can tell the framework to call a specific method if a particular service goes offline, or to call your deactivate() method if any of the services you absolutely depend on advertises that it is not working. In the end you have much more confidence that the (service) objects you refer to are actually valid than in a supposedly less dynamic environment. I know from experience that some developers have difficulties accepting that there we are living in an imperfect world and they are already developing unreliable software - but in the end they have to, otherwise as Peter says they will build brittle systems, and then they will be hurt and confused when these systems fail. > Hey All, > > Every other week a new developer comes around and starts asking those > smarty pants questions: > > Q: .. what about holding references, and bundles/services coming and going > during this time?? > > It makes me violent! > > Does anyone know of a document that discusses this topic so as I can > simply > point them at it without having to enter into another often heated debate > about it? > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com> (@Liferay) > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
