Dependency Injection in OSGI environments

Question

First some background:

I\'m working on some webapp prototype code based on Apache Sling which is OSGI based and runs on Apache Felix. I\'m still relatively new to OSGI

Answer 1

I'd just like to add a little more information to Robert's excellent answer, particularly with regard to JSR330 and DS.

Declarative Services, Blueprint, iPOJO and the other OSGi "component models" are primarily intended for injecting OSGi services. These are slightly harder to handle than regular dependencies because they can come and go at any time, including in response to external events (e.g. network disconnected) or user actions (e.g. bundle removed). Therefore all these component models provide an additional lifecycle layer over pure dependency injection frameworks.

This is the main reason why the DS annotations are different from the JSR330 ones... the JSR330 ones don't provide enough semantics to deal with lifecycle. For example they say nothing about:

• When should the dependency be injected?
• What should we do when the dependency is not currently available (i.e., is it optional or mandatory)?
• What should we do when a service we are using goes away?
• Can we dynamically switch from one instance of a service to another?
• etc...

Unfortunately because the component models are primarily focused on services -- that is, the linkages between bundles -- they are comparatively spartan with regard to wiring up dependencies inside the bundle (although Blueprint does offer some support for this).

There should be no problem using an existing DI framework for wiring up dependencies inside the bundle. For example I had a customer that used Guice to wire up the internal pieces of some Declarative Services components. However I tend to question the value of doing this, because if you need DI inside your bundle it suggests that your bundle may be too big and incoherent.

Note that it is very important NOT to use a traditional DI framework to wire up components between bundles. If the DI framework needs to access a class from another bundle then that other bundle must expose its implementation details, which breaks the encapsulation that we seek in OSGi.