Hi Marcel, thanks for the explanations…. more quibbling inline :-) On Oct 15, 2013, at 1:33 PM, Marcel Offermans <[email protected]> wrote:
> Hello David, > > On Oct 15, 2013, at 19:51 PM, David Jencks <[email protected]> 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). Do you have an example? The "requires service A and configuration B" sounds like in DS a 1..1 reference to A and ConfigurationPolicy.REQUIRE. What adds the dependency on C? How does this differ from including the C.target property in the configuration? > > 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. From my quick look at the docs it looked like these examples basically registered another service exposing the same interface and with a dependency on the original service, something that is easy to do with DS as well. I didn't see the factory aspect described….. again, is there a more sophisticated example? > > 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'd like to look at this, can you point me to the code? > >> 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). I was thinking of creating a non-xml way to add the same kind of information as in the xml, I think you might describe this as making DS dynamic. thanks! david jencks > > 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 >
