In addition to the responde made by Paul, I confirm that the new major DM 4.0.0 version will come soon (see [1]).
Also there is another benchmark that has been made for DM4. It is probably not a prefect benchmark, but it's simple and it allows to test basic features, like service dependencies. If you are interested, you can also take at the benchmark, which is described in the README file from svn code at [2]. [1] http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/ [2] http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dm.benchmark/ kind regards; /Pierre On Thu, Jul 17, 2014 at 1:28 PM, Paul Bakker <paul.bak...@luminis.eu> wrote: > 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 <b...@romandie.com> 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 <b...@romandie.com> 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: users-unsubscr...@felix.apache.org > >>> For additional commands, e-mail: users-h...@felix.apache.org > >>> > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > For additional commands, e-mail: users-h...@felix.apache.org > > > > >
