About your DM questions: - The reason it requires fields to be volatile and non-final is that services can come and go during runtime (like you already experienced). That's why it must be possible to re-inject instances into an already existing component. The reason for volatile is that there may be multiple threads working with a component, and volatile prevents readability issues caused by caching.
- It's slightly more expensive than DS, but it's not far off. There was a nice presentation given by two of my colleagues about performance of DM,DS, iPojo and blueprint recently: http://www.slideshare.net/mfrancis/the-ultimate-dependency-manager-shoot-out-x-uiterlinden-s-mak - You can use annotations as well: http://felix.apache.org/site/apache-felix-dependency-manager-using-annotations.html - No, a vote for a new release was just started two days ago, and development for the next major version is almost completed. I have a preference for DM, but like Neil said; both are fine. Cheers, Paul On Thu, Jul 17, 2014 at 12:18 PM, Bulu <[email protected]> wrote: > Thanks for the answers so far. > > Basically I now have to choose one of two methods (declarative services vs > dependency manager). > Possible arguments besides ease-of-use are performance, maintenance of the > library and backporting to existing code. > > My current understanding is that "Felix Dependency Manager" > - requires the injected fields in target classes to be volatile (and not > final - I like immutable data - can't we pass references on construction?) > - uses reflection extensively (performance?) > - the wiring has to be made in the Activator, where the DependencyManager > reference is available (or pass it around) > - the doc has not been updated since 2010. Does this indicate, that the > project is sleeping? > > Declarative services: > - is part of the OSGi standard (which makes it more future proof I guess) > - requires you to hack XML (beuh) or use annotations (bndtools), so > classes are not so pure POJOs > - wiring can be made from anywhere > > Are theses points correct? What do you recommend? > > Is setting up integration testing with either lib easier? > > Regards Philipp > > > > > > > On 17.07.2014 10:19, Paul Bakker 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] >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
