felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bakker <paul.bak...@luminis.eu>
Subject Re: Building better OSGi applications
Date Thu, 17 Jul 2014 11:28:42 GMT
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:

- You can use annotations as well:
- 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.



On Thu, Jul 17, 2014 at 12:18 PM, Bulu <bulu@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 <bulu@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message