The last item to update is the project pom.xml file. Its contents are very close to the ones we've already seen relating to iPOJO, with a few differences that we will look at here. The version of the bookshelf-service-tui bundle will now be 1.9.0.
The Maven dependency for the iPOJO annotations we've used previously need to be added to the dependencies section:
<dependency> <groupId>org.apache.felix</groupId> <artifactId>org.apache.felix.ipojo.annotations</artifactId> <version>1.6.4</version> </dependency>
The build plugins sections for maven-bundle-plugin and maven-ipojo-plugin will look like:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.1.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Category>sample</Bundle-Category>
<Bundle-SymbolicName>${artifactId}</Bundle-SymbolicName>
<Export-Package>
com.packtpub.felix.bookshelf.service.tui
</Export-Package>
</instructions>
<remoteOBR>repo-rel</remoteOBR>
<prefixUrl>file:///C:/projects/felixbook/releases</prefixUrl>
<ignoreLock>true</ignoreLock>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-ipojo-plugin</artifactId>
<version>1.4.2</version>
<executions>
<execution>
<goals>
<goal>ipojo-bundle</goal>
</goals>
<configuration>
<metadata>src/main/ipojo/meta.xml</metadata>
</configuration>
</execution>
</executions>
</plugin>
You'll notice that it is only slightly different than the others we've seen so far.
We've practiced iPOJO using both XML-based and annotation-based configuration of components. How about you try to move the other two bundles (bookshelf-inventory-impl and bookshelf-service) to use annotations?
Items to keep in mind while doing this:
- Remember that the XML configuration takes precedence over annotations. You'll need to remove component declarations from the XML configuration to switch to newly added annotations.
- Unless for very simple cases, it's not recommended to use the Instantiate annotation to request an instance of the component (see previous topics for a short discussion on that).
The result would functionally be the same as what we currently have.
One of the nice features of iPOJO is that it manages a component's dependencies out of the box. This means that it will ensure the dependency is injected with its implementation, when one is available.
Also, we now know how to define a component's required properties.
This is an opportune time to write another implementation of the BookInventory service, as a new bundle (say, bookshelf-inventory-impl-file), which would store the book data to a file.
Here are some hints for this:
- Make the component require a property, which is the path to store the books in, relative to the framework's persistent storage area. Access to the framework's persistent storage area is provided by the
BundleContext's getDataFile()method - Make the service load the contents of the stored books on start-up and index them for search. This is done by specifying a callback on
validatethat will load all stored books.
When the implementation is complete, it's enough to uninstall the older one (bookshelf-inventory-impl-mock) and install and start the new implementation (bookshelf-inventory-impl-file). The new implementation will be injected into the bookshelf service inventory field automatically.