Philipp; errata: the correct link for the DM documentation is http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
kind regards; /Pierre On Thu, Jul 17, 2014 at 11:27 AM, Pierre De Rop <[email protected]> wrote: > Hi Philipp; > > I'm using DM and DS in some large applications (~400 bundles, ~1000 > services), and I confirm that both DM and DS are fast. > > If you want to give a try to DM java API, you can take a look at [1]. it's > a simple but powerful API, which allows to not only declare simple > services, but also service aspects (interceptors), service adapters, > configuration dependencies, etc ... > > DS will also allow you to declare your services easily. As suggested by > Ferry, you can take a look at the bndtools faq from [2], but the FAQ from > [3] is also useful and concise. > > [1] http://felix.apache.org/site/apache-felix-dependency-manager.html > [2] http://bndtools.org/tutorial.html > [3] http://wiki.osgi.org/wiki/Declarative_Services > > hope this helps; > > kind regards; > /Pierre > > > On Thu, Jul 17, 2014 at 10:19 AM, Paul Bakker <[email protected]> > wrote: > >> 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] >> > >> > >> > >
