Byte-code weaving —i POJO instruments component byte code, which enables it to
provide features not possible (or easily possible) with other approaches.
Metadata format agnosticism —Whereas other approaches force you into using
the single approach they support to describe your components ( XML , annota-
tions, or API ), i POJO allows you to use any of these approaches.
High level of extensibility —The component man-
agement features provided by the i POJO com-
ponent container are implemented by handlers
from which you can pick and choose. You can
also create custom handlers for specific man-
agement tasks; see figure 12.4.
In most of the remainder of this chapter, we'll explore
the features of i POJO , but we won't cover everything.
For starters, we'll focus on using the annotation
approach for describing components, because you've
already seen enough XML and API . But keep in mind
that everything you do with annotations you can do
with the XML - and API -based description approaches—
it depends on your preference.
Figure 12.4 iPOJO components
are an aggregation of handlers
attached to the component
container at execution time.
Building iPOJO components
i POJO uses byte-code manipulation to instrument component class files. This instru-
mentation inserts hooks into the component class file so it can be externally man-
aged. Although i POJO also supports execution-time byte-code instrumentation, the
simplest way to get it done is with a build-time step to process your components. To
achieve this, i POJO integrates with Ant, Maven, and Eclipse. As an example, here's the
Ant task for the circle bundle:
metadata = "OSGI-INF/circle.xml"/>
Upon completion of this build step, i POJO has instrumented the byte code of any
components contained in the referenced bundle. The details of how i POJO instru-
ments the component byte code aren't as important; but for the curious, i POJO instru-
ments all components in a single, generic way to enable intercepting member field
and method accesses. All functionality provided by the i POJO component framework
(providing services, requiring services, and so on) is provided by handlers using these
interception hooks. The hooks themselves don't change the component behavior; the
modified component classes behave the same as before and can still be use without
i POJO , although they now have some code dependencies on it.