Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Why DependencyManager rather than DS?
From: Marcel Offermans <marcel.offermans@luminis.nl>
In-Reply-To: <D8A23E65-9659-4A93-B9DE-79AF990A3E02@yahoo.com>
Date: Tue, 15 Oct 2013 22:33:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D52EF26D-04A6-4942-80FF-F0F6083EBE27@luminis.nl>
References: <D8A23E65-9659-4A93-B9DE-79AF990A3E02@yahoo.com>
To: <dev@felix.apache.org>

Hello David,

On Oct 15, 2013, at 19:51 PM, David Jencks <david_jencks@yahoo.com> =
wrote:

> After seeing a lot of commit activity on DependencyManager I decided =
to try to understand what it's for, and after looking at the =
documentation I'm still not sure.  It looks to me like the main feature =
is a fluent api that provides something like DS, although less =
declaratively, and then there are some special cases that might be =
slightly simpler than just declaring a service that does the same thing =
(aspects, temporal)

DependencyManager has its roots long time ago, when there was no =
Declarative Services specification yet. It started when I was working on =
my first big OSGi project (about 10 years ago) and we needed a library =
to help us declare and manage dependencies.

The only library at that time was "servicebinder", which was somewhat =
similar to what became DS. We evaluated that library for our project, =
but it did not fulfill all our use cases.

Most importantly, we had use cases that required us to declare =
dependencies at runtime, for example based on configuration data or some =
hardware aspects we discovered at runtime. Furthermore, I did not like =
the XML configuration, which did not automatically update when =
refactoring your code and did not have code completion or syntax =
checking.

That last bit has been improved now that DS supports annotations to =
generate XML.

> So as a DS partisan :-) I'm wondering what the big advantages of =
DependencyManager are.

DS still can't do dynamic dependencies, nor is it extensible to support =
new types of dependencies (DM comes with dependencies to track services, =
configuration, bundles and "resources". To give an example, DM can =
declare a component that requires service A and configuration B. As soon =
as it has both, the component can evaluate configuration B and depending =
on its contents add another service dependency C (or something like =
that).

DM also has concepts like aspects and adapters, that allow you to =
declare factories that automatically generate components that attach to =
other services. In the case of aspects creating a whole "chain" of =
services, allowing you to easily intercept existing services and add =
behaviour such as adding a cache to a store. In the case of adapters =
allowing you to add for example management capabilities to services.. =
Just to name a few examples. This really deserves a longer description, =
but this gives you a general idea.

A third feature that might be interesting is that DM also has support =
for "indices" that dramatically speed up the OSGi service registry when =
you're dealing with applications that consist of lots of services =
(1k-10k or even more). It uses a technique similar to what relational =
databases use to speed up lookups. Xander did a lot of work on this, =
they have a huge application that used to take about 30 minutes to start =
up and now does so in more like 30 seconds (so orders of magnitude =
speedup).

> I also wonder if it would be useful to add to DS a fluent api for =
adding components at runtime.  I think this would be pretty easy, just =
construct ComponentMetadata and add it to the appropriate =
BundleComponentActivator.

Creating the fluent API would not be too hard, but DS is not dynamic, =
you need to package the XML with the bundle for it to work, so that part =
would be harder to fix (unless you resort to generating bundles on the =
fly or something like that).

The other way round would be easier: creating an extender bundle that =
reads the XML descriptors that DS uses and using DM to create the =
appropriate components.

For the record, DM currently also has an annotation based API, =
contributed a while ago by Pierre and Arjun.

Greetings, Marcel