An iPOJO 1.4.0 overview
Finally! The last week, the iPOJO team released the iPOJO 1.4.0 version of the framework. This new version fixed several bugs but also provides new features. This post gives on overview of the novelties provided in this opus.
The API to describe iPOJO component type in Java
iPOJO supports XML & annotation based descriptions. The iPOJO API provides a way to create /declare new component types & instances at runtime. This is a very convenient way against annotations and XML allergies! This API was designed to be easy to use, avoids redundancies… Here a small example creating a service provider and a service consumer:
public void create(BundleContext bc) throws Exception {
new PrimitiveComponentType()
.setBundleContext(bc)
.setClassName(HelloServiceProvider.class.getName())
.addService(new Service()
.addProperty(
new ServiceProperty().setName("language")
.setType(String.class.getName())
.setValue("en")
))
.createInstance();
new PrimitiveComponentType()
.setBundleContext(bc)
.setClassName(HelloServiceConsumer.class.getName())
.addDependency(new Dependency().setField("hello"))
.setValidateMethod("start")
.createInstance();
}
The POJO classes are manipulated at runtime if required.
An interesting property of the API is the iPOJO composite support. So you can easily describe applications natively dynamic. To illustrate that, let’s imagine a pretty simple application compared by 2 instances from 2 types (potentially described with the API). This application is described and instantiated as follow:
new CompositeComponentType()
.setBundleContext(bc)
.addInstance(new Instance("MyProviderType"))
.addInstance(new Instance("MyConsumerType"))
.createInstance();
Last but not least, the API is bound with the introspection and reconfiguration mechanism of iPOJO. For reconfiguration adepts (Autonomic, context-aware applications), it simplifies the reconfiguration process. Thanks to this feature, it is pretty easy to declare a component type, create an instance of this type, and then, later, reconfigure its service dependency:
Dependency dependency = new Dependency().setField("hello");
ComponentInstance instance = new PrimitiveComponentType()
.setBundleContext(bc)
.setClassName(HelloServiceConsumer.class.getName())
.addDependency(dependency)
.setValidateMethod("start")
.createInstance();
dependency.getDependencyDescription(instance).setFilter(bc.createFilter("(language=en)"));
Interesting, isn’t it? And that’s just an overview!
Online Manipulator
The second great novelty is the online manipulator. Let’s sum up the story. A lot of users were complaining about the additional packaging step to create iPOJO bundle. This step prepares the bundle to be managed by iPOJO. So despite tools such as Ant and Maven doing this preparation seamlessly (once configured), it’s trickier with tools as Eclipse. The online manipulator just removes this additional step. In fact, it does this process during the deployment of the bundle. To use, the online manipulator, just prefix your bundle URL with ipojo://. That’s it. It looks for the metadata.xml file inside the bundle and executes manipulation. You can also specify or override the metadata in the URL:
install ipojo:file:/tmp/mybundle.jar!file:/tmp/mymetadata.xml
Thanks to the online manipulator, you can use any tools to develop your bundle such as the Eclipse PDE. Just awesome!
Web Console Plugin
Finally, the last novelty is really interesting for those development complex applications with iPOJO. The Web Console Plugin is an Apache Felix Web Console extension giving data about your iPOJO applications.
It’s a Web based alternative to the «arch» command. The plugin displays the created instances, available factories and handlers. For all those entities, details are given such as the current state, provided services (and properties), used services… The model is navigable! So, for a service dependency, you can directly navigate to the used iPOJO instance, from an instance, you can switch to the factory (i.e. component type) and see all the instances from this type. For «arch» command user, the « raw » architecture is also given. This plugin definitively helps debugging iPOJO applications by giving everything required to understand the reasons to unsatisfied service dependencies, invalid instances or factories.
Conclusion
That’s all for the biggest novelties of iPOJO 1.4.0. It’s not only improvements. See the release notes for more details.
Moreover, the road map of the next version is also promising: proxy support, constructor injection, transaction support and persistence. And that’s just a couple of example. So one advice, stay tuned!
Posts
