On 17/07/14 10:04, Bulu wrote:
Hi all I'm building an application on an embedded system which will contain ~20 bundles. There are many dependencies of services - say for example to provide its service, module A (several classes) needs services B,C,D. In order to fully account for the dynamics of OSGi, I have to monitor B,C,D to stop A when any of these 3 goes away. This unregisters service A, which in turn will disrupt all clients of A. If additionally you want to handle part case (A should still provide a reduced service, if only B and C are available but not D) it gets messy rapidly. In the end, I realize that I am mostly writing life cycle code instead of business logic and I have lots of OSGi dependencies, with the BundleContect passed around nearly everywhere. This smells like bad design. Could you share insights or recommend reading on how to structure OSGi services for cohesion and modularity, to avoid the problems above? Are there ways to reduce the boiler plate? Should I be investigating declarative services, iPojo or others (in general I prefer writing code than XML...). As this is an embedded system, should I be worried about the performance impact of DS?
I'd suggest that you look into Declarative Services (DS). It's model is very straightforward and it reduces your boilerplate to almost zero.
I tend to use it for almost all my bundles. Take a look at the bndtools tutorial for a quick start.
Thanks for your insights Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
-- Ferry Huberts --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
