The component element declares a service that is to be handled by iPOJO. The component's target class is set through the classname attribute. An optional name can be given to the component and used to reference it.

The component element also declares what it provides to iPOJO, the framework, and what it requires from them.

The<provides/> and<requires/> elements have a rich set of declarative options, most of which are not covered here. We will focus on the basics needed for the integration.

For example, a component can provide a service, which is registered using the component's interfaces. It can also provide properties to be published with the service.

Examples of things a component can require are lifecycle callbacks (the component provides a method to be called when a lifecycle stage is achieved) or services that it needs set through injection.

Once you're comfortable with the use of iPOJO, it's recommended that you read about some more of those and experiment with them. For now, let's focus on a simple configuration; the one we'll put in place for our bookshelf service:

<component
name="BookshelfServiceImpl"
classname=
"com.packtpub.felix.bookshelf.service.impl.BookshelfServiceImpl">
<provides />

The component classname is specified along with an optional name. If the name is not set, the class name will be used instead.

The<provides /> element tags the component as providing a service based on the interfaces it implements. iPOJO will register instances of this component with the framework.

The service also requires its inventory field to be injected with an instance of a BookInventory.

<requires field="inventory" />
</component>

There's no need to tell iPOJO the type of the required injection. It will find out on its own by inspecting the type this field is declared as in the component class.

Callbacks involve the instances of the component during stages of its life-cycle. Basically, the component optionally provides a method to be called as it is validated and invalidated. In this case, we don't need it, but the syntax would be as follows:

<callback transition="validate" method="start" />
<callback transition="invalidate" method="stop" />
</component>

In the previous syntax, the start() method of the component would be called on component validation and the stop() method would be called during its invalidation. The callback target method names are arbitrary (that is, they don't have to be called start and stop).

The instance element requests the creation of an instance of a declared component. It specifies the component that needs to be instantiated, and an optional name for it, as well as the configuration of properties of the instance.

In our case, we're creating an instance of the component "BookshelfServiceImpl" that we've previously declared. We will name it bookshelf.service.impl; this name will appear later when we inspect the instances that iPOJO has detected.

<instance
component="BookshelfServiceImpl"
name="bookshelf.service.impl" />

If needed, properties that the component requires can also be set when declaring the instance:

<instance component="name-ref" name="inst-name">
<property name="propName" value="propValue"/>
</instance>

In our case, the required field is an instance of a component that iPOJO already manages. We, therefore, don't need to worry about setting it here.

Our final iPOJO meta.xml would look like this:

<ipojo
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="org.apache.felix.ipojo
http://felix.apache.org/ipojo/schemas/CURRENT/core.xsd"
xmlns="org.apache.felix.ipojo">
<component classname=
"com.packtpub.felix.bookshelf.service.impl.BookshelfServiceImpl"
name="BookshelfServiceImpl">
<provides />
<requires field="inventory" />
<requires field="log" />
</component>
<instance
component="BookshelfServiceImpl"
name="bookshelf.service.impl" />
</ipojo>

We will see all this again as we modify our bundles.