Definetly use either Felix Dependency Manager (that's what I use on all projects) or Declarative Services. DS is slightly simpler, DM is more powerful. The main difference is that DM can also be used from code to register/deregister components at any given time. Both solutions will solve the problem you are describing, which is a very common one :-)
Cheers, Paul On Thu, Jul 17, 2014 at 10:04 AM, Bulu <[email protected]> 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? > > > Thanks for your insights > Philipp > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
