Building dynamic applications with OSGi services - Enterprise OSGi in Action - page 141

6.2.4 iPojo

We mentioned earlier that you'd be spoiled for choice in terms of dependency injec-
tion frameworks—or perhaps confused! Not only does the OSG i alliance specify two
different dependency injection frameworks, Blueprint and Declarative Services, the
Apache Felix project itself includes several subprojects for dependency injection: Ser-
vice Component Runtime (a Declarative Services implementation), Dependency
Manager, and iPojo. iPojo isn't a standard, so you're restricted to the one iPojo imple-
mentation. But it supports configuration by XML , annotations, and even API . It uses
bytecode instrumentation internally, which makes it more invasive than Declarative
Services, but also more powerful.
iPojo is extremely sophisticated, and we'll only scratch the surface of it here. In its
simplest form, iPojo looks a lot like SCR annotations, except that it uses a @Provides
annotation instead of an @Service annotation to indicate that a component should
be exposed as a service:

@Component
@Provides
public class DesperateCheeseOffer implements SpecialOffer {
Similarly, injected services are marked with a @Requires annotation:

@Requires
Inventory inventory;
More fundamental differences become apparent when you try to do more involved
things; iPojo has more support for lifecycle callbacks and complex dependency rela-
tionships than Declarative Services. It also supports stateful services by providing guar-
antees that a thread in a given context will always see the same service instance.
Because it uses bytecode instrumentation, in general iPojo requires an extra build
step to insert the required bytecode. Build tasks and plug-ins are available for Ant,
Maven, and Eclipse. iPojo does also provide a runtime enhancement feature,
although this adds an unpleasant ordering dependency between iPojo and the bun-
dles it extends.

6.2.5 Google Guice and Peaberry

Blueprint, Declarative Services, and iPojo were all designed with OSG i in mind, but
dependency injection isn't restricted to the OSG i world. Some of the non- OSG i depen-
dency injection frameworks can also be adapted to work in an OSG i environment. In
particular, a framework called Peaberry has been added to Google Guice that allows
OSG i services to be exposed and consumed.
One feature of Peaberry that makes it different from the other frameworks here is
that there's nothing OSG i-specific about it. It can be extended to use any service registry
(for example, integrations with the Eclipse extension registry are available). It can also
use ordinary Guice injection. This means it's easy to use the same client code in a variety
of different contexts. The big problem with Peaberry comes from the fact that it isn't