iPOJO's Dark Side

2009-08-03T17:18:00.004+02:00

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!

Android talk at Linuxtag

2009-06-26T10:34:00.003+02:00

Yesterday I gave with Karl Pauls a talk about Android at Linuxtag.
It was great: 70 to 80 people, a lot of questions ...
I just updated the slide, so, if you're interested by Android and maybe OSGi, just have a look.

Android : a linux-based mobile operating system

View more documents from clement.escoffier.

OSGi devcon Talks

2009-06-23T16:28:00.003+02:00

Just back from OSGi Dev Con Europe. The conference was great and the talk quality was very good. Here are my presentations:

Transactional OSGi Applications Done Right

View more OpenOffice presentations from clement.escoffier.

Experimenting with the OSGi platform in the Aspire RFID middleware

View more OpenOffice presentations from clement.escoffier.

You can look at the others presentation on OSGi devcon Europe 2009 group

The Junit4OSGi - Pax:Exam mix

2009-05-03T09:12:00.002+02:00

Half of both, shake, enjoy …

In the OSGi world, there is different ways to test “bundles” / “systems” / “applications”.

Spring Integration Testing fit very well with Spring applications, but in all the others cases it doesn’t work very well.

BND Testing Harness is a testing framework integrated with BND. Despite very powerful to generate bundle on the fly, it sounds not very adequate when test must be integrated inside a build process expect Ant and Eclipse (such as Maven).

Junit4osgi is a very simple test framework, running junit 3 tests on OSGi. The goal was to provide a simple way to write tests checking services … junit4osgi also provides high-level method simplifying the OSGi test writing.

Finally, pax:exam is a test framework for OSGi allowing to finely configure the test framework.

Recently, I discuss with the pax:exam developers about providing THE test framework for OSGi. In fact, I was considering moving the iPOJO test suites and the application test suites that I developed to pax:exam. After trying pax:exam, I was finally able to understand what pax:exam provides and what would be great…

Requirements
First what are the requirements of a cool test framework for OSGi.

To begin, it has to reuse existing “test engine” such as junit or testNG. Java developers have already developed tests with those frameworks (I hope so…), and so this should ease the OSGi test writing.

Then, as you know, testing is never a very exiting task. So, the test framework should provide high-level methods to ease the OSGi integration. Methods such as “getService”, “waitForService” … should be provided and so the developer can focus on testing its service and not how to get the service.

Third important point: the configuration. The application/service have to be deployed and run is a “real” OSGi platform. This platform has to be configured. This configuration contains obviously the bundles to deploy but can also contain other properties (extra packages, system configuration…). Supporting several OSGi implementation and several dependent bundle package is also a good property.

Another important aspect related to the configuration is the dispatching test / platform. This should allow configuring which tests have to be deployed and execute on the SAME frameworks. Despite this can create side effects; sometimes we are looking for those side effects.

The test framework must provide a “seamless” integration with build process and development tools such as Ant, Maven, Eclipse… Tests should be executed when the project is built, and developer should be able to execute quickly their tests from their favorite IDE.

OSGi defines Execution-Environment. The minimum environment is J2ME Foundation Profile 1.1. The test framework should provide a mode allowing executing test on this environment. Indeed, sometimes we want to check that everything works on a production-like environment or on different Java Virtual Machine.

Finally, the test framework should provide a way to execute the test manually on a “regular” platform. This way allows debugging what does not work. The developer recreates the environment or uses the production environment, deploys its tests and executes them manually.

Junit4osgi / pax:exam : The comparison

Test Engine

Junit4OSGi: junit3 only
Pax:Exam: sub-set of junit4 (no afterClass and beforeClass), possibility to support others test engines.

High-Level method

Junit4OSGi: Helper pattern (osgi (bundle, service, package admin), ipojo, config admin, event admin…)
Pax:Exam: just the bundle context

Configuration

Junit4OSGi: all maven dependencies that are bundles + system properties. Use Felix only
Pax:Exam: @Configure method allowing to finely configure that framework (provisioning, Maven helper…). Allow running test on several configuration (OSGi implementation…).

Platform / Test

Junit4OSGi: one framework per Maven project
Pax:Exam: One framework per @Test method

Build Process / IDE integration

Junit4OSGi: Maven integration, possibility to manually launch the tests
Pax:Exam: Maven, any IDE (at least Eclipse)

Execution-Environment

Junit4OSGi: J2ME Foundation Profile 1.1
Pax:Exam: Java 5

Manual launching

Junit4OSGi: Yes, all the tests are inside a bundle
Pax:Exam: No, must use the regular test runner

Diving into pax:exam
I recently tried pax:exam and developed a couple of tests with it. It is really a promising framework, and the integration of the junit4osgi features is now on the roadmap. However, I have a couple of complaints and solutions:

pax:exam fits very well to test OSGi applications, but to test framework we need a way to create on the fly bundles. Pax:exam does not provide natively such kind of feature. However, Tony Menzel developed tinybundle, a small and simple API to create bundle on the fly. I extended it a little bit to support iPOJO bundles. So, I’m able to create iPOJO bundles on the fly inside my tests! Definitely great.
The pax:exam development model relies on the bundle context. As a junit4osgi power user, I want high-level method. I just externalized junit4OSGi helpers, and so was able to reuse all the junit4osgi methods.
Pax:Exam is definitely slow… As it creates one framework per @Test method, it’s really inefficient when your test suite contains thousands of tests. I have 2000 tests with junit4osgi. Executing all of them takes almost 5 minutes (I have very expensive test with asynchronous event handling…). I also have a test suite developed with pax:exam of 20 tests. Such suite is executed in 3 minutes. So, there is definitely a performance / time issue. However, the pax:exam team is developing a Felix container as the junit4osgi one. This will improve performance.
A way to execute junit3 tests (working on Foundation Profile 1.1) and TestNG tests would be great.
A way to create test bundles “deployable” manually on a manually configured platform

So, in conclusion, pax:exam is a promising framework. I’m looking forward the next improvements and hope that junit4OSGi features will be provided soon.

Resources
Junit4osgi: http://felix.apache.org/site/apache-felix-ipojo-junit4osgi.html
Pax:exam: http://wiki.ops4j.org/display/paxexam/Pax+Exam
BND Testing Harness: http://felix.apache.org/site/bnd-testing-harness.html
Spring Integration Testing: http://springosgi.googlepages.com/ch04.html
Junit 3: http://junit.sourceforge.net/junit3.8.1/index.html
Junit 4: http://www.junit.org
TestNG: http://testng.org
Helper class to ease test writing: http://svn.apache.org/viewvc/felix/trunk/ipojo/tests/api/src/test/java/org/apache/felix/ipojo/tests/api/
Tinybundle: https://scm.ops4j.org/repos/ops4j/projects/pax/swissbox/pax-swissbox-tinybundles/
iPOJO extension to tinybundle: http://svn.apache.org/viewvc/felix/sandbox/clement/BundleAsiPOJO/

Customized service object creation with iPOJO

2009-04-14T19:01:00.004+02:00

The last week, I attended to the OSGi in Action talk organized by the Java User Group Berlin – Brandenburg. Karl did a very nice talk, but I was definitely more interested by the questions ☺
One of the questions was about the service object creation policy. The person asking for this, was a little worried by the default OSGi policy: publishing the service object itself in the service registry. I can understand his issue: why creating something not necessary needed (lazy creation), and how can I deal with multiple service objects.

So, the answer is definitely the Service Factory. When publishing a service factory instead of the service object, the framework notifies you each time a NEW bundle asks for a service object. So, you can create the service object at the first call or create one service object each time a new bundle asks for the service. In fact, the OSGi framework caches the returned object in order to improve performance.

However, it’s weird to add this “bundle” concept there. How I can create one service object per call or per user, or per thread? Those creation policies make sense in a lot of context. The traditional OSGi answer relies on the “Facade” design pattern. You registers an object that delegate the invocation on the “good” object. You can create the “good” object regarding to your creation policy.

However, I was never really happy to implement this facade pattern in the code. Why? Just because it’s typically something that:

Pollute your code
Can be externalized

Inside iPOJO, I tried to remove this limitation by adding a third creation policy. It is possible to provide a service and to create one service object per asking instance. So, two instances will use two different service object despite they are in the same bundle!

In fact, iPOJO provides a way to specify your own creation strategy. Imagine that you have a specific creation policy. Just implement the desired behavior by creating a class extending CreationStrategy. Moreover, iPOJO brings a new concept called IPojoServiceFactory closed to OSGi Service Factory but based on instance. So, if an iPOJO instance requires a service implementing this interface, the iPOJO container will call a special method to get the service object. This method will be called every time the service is get (so not only once per instance). However the creation strategy may decide to return always the same service object for one instance (per instance strategy).

So, how I can create my own fine-grained creation policy?

Just create a class extending the CreationStrategy class and implements the IPOJOServiceFactory interface.

So, let’s say that your OSGi Service Factory getService method is called. So you return a proxy/facade extending the IPOJO Service Factory interface like in


public Object getService(Bundle arg0, ServiceRegistration arg1) {
            Object proxy = Proxy.newProxyInstance(getInstanceManager().getClazz().getClassLoader(),
                    getSpecificationsWithIPOJOServiceFactory(m_serviceSpecification, m_handler.getInstanceManager().getContext()), this);
            return proxy;
        }

When another iPOJO instance will asks for your service, it will call the iPOJO Service Factory getService method. Then, you intercept this method and apply your creation strategy. For example, the next snippet shows the per instance creation strategy:


public Object invoke(Object arg0, Method arg1, Object[] arg2) {
            if (isGetServiceMethod(arg1)) {
                return getService((ComponentInstance) arg2[0]);
            }
           
            if (isUngetServiceMethod(arg1)) {
                ungetService((ComponentInstance) arg2[0], arg2[1]);
                return null;
            }
           
            throw new UnsupportedOperationException("This service requires an advanced creation policy. "
                    + "Before calling the service, call the getService(ComponentInstance) method to get "
                    + "the service object. ");
        }


        public Object getService(ComponentInstance instance) {
            Object obj = m_instances.get(instance);
            if (obj == null) {
                obj = m_handler.getInstanceManager().createPojoObject();
                m_instances.put(instance, obj);
            }
            return obj;
        }

public void ungetService(ComponentInstance instance, Object svcObject) {
            Object pojo = m_instances.remove(instance);
            m_handler.getInstanceManager().deletePojoObject(pojo);
        }

You can easily change this code to implement your own strategy like one per thread... As you get the ComponentInstance object, you can easily look for properties… and so create very sophisticated strategies.

So, thanks to this mechanism, you can creation you own policy and refer to it from your provides metadata:


    <component
        classname="…FooBarProviderType">
        <provides strategy="….MyCreationStrategy">
    </component>

That’s it!

The main and major limitation of these strategies is that they rely on iPOJO. So both the provider and the consumer have to be developed with iPOJO to deal correctly with the new service object creation policy. So, just use iPOJO ;-)

iPOJO and File Install : configuring iPOJO instances with 'cfg' files

2009-04-01T17:10:00.007+02:00

FileInstall is a great bundle to provision your system. It watches a directory and installs every bundles contained inside the directory. Moreover, it’s fully support the configuration admin. So, it reads .cfg files contained in the folder and pushes the read configuration into the configuration admin.

iPOJO also supports the configuration admin. iPOJO instances can be created, deleted and reconfigured from the configuration admin.

So, why not creating, reconfiguring and deleting iPOJO instances from the cfg files.

File Install philosophy

File install is great and simple. It just has one general idea to understand:

The content of the watched folder is your system configuration

So, if you create cfg files inside this folder, those files will be analyzed and the configuration pushed in the configuration admin. To remove the configuration, just remove the file from the folder!

Note: Don’t forget to install the configuration admin

Using File install to create instances

When you declare an iPOJO component, this will expose a ManagedServiceFactory service. [Except if you voluntary set the component type to private]. This service can be used to create / reconfigure/ delete instances of this component type.

So, let’s say that we have the following bar.Foo class:


@Component
public class Foo {
 @Property
 private String name;

 …
}

This declare an iPOJO component type (named bar.Foo (i.e. the classname) as no name is specified). This component type also declares a property (name).

So, once deployed, iPOJO will exposed a ManagedServiceFactory service with the ‘bar.Foo’ service pid. The configuration admin will push all matching configuration to this ManagedServiceFactory.

Now, let’s say that File install watches the ‘load’ folder. If you create a file named bar.Foo-1.cfg containing the following content:

name = the name

Once saved, File Install will find it, analyzes it and pushes the configuration to the configuration admin. The configuration admin will pushes this configuration to our ManagedServiceFactory, and so we just create an instance of our type!

So, cfg files completely replaces the tag of iPOJO metadata files. You no more need them (if you use annotations).

Let’s create a second file named bar.Foo-2.cfg containing the following content:

name = the second name

This will create another instance.

Reconfiguring an instance

To reconfigure an instance, just edit the cfg file. For example, edit the bar.Foo-2.cfg and change the name property to ‘a third name’. The instance will be automatically reconfigured.

Deleting an instance

To delete an instance, just remove the cfg file (containing the instance configuration) from the file install folder. That’s it! The watched folder is your system configuration.

The ManagedService case

So, let’s imagine that you don’t want to create instances from cfg file but just reconfiguring them. It’s also possible. File install also supports Managed Service, and so, will pushed a Managed Service configuration inside the configuration admin.

If you use this way, you have to create the instance yourself (from the metadata.xml file for example).
First, let’s modify our component type:


@Component(managedservice="MyPID")
public class Foo {
 @Property
 private String name;

 …
}

and create the metadata.xml file declaring an instance of this type:


<ipojo>
<instance component="bar.Foo"/>
</ipojo>

The “managedservice” attribute of the @Component annotation allows setting the service pid of the Managed Service. So, iPOJO will expose a ManagedService allowing reconfiguring your instance with the “MyPID” pid. [You can also set the managedservice pid from the instance configuration].
So, to reconfigure the instance, create a cfg file named MyPID.cfg containing the configuration such as:

name = a name

When you save the file in the watched folder, File install will pushes the configuration to the configuration admin. Then, the configuration admin will look for the matching ManagedService (the one with the MyPID service.pid) and pushed the configuration. So, your instance will receives the configuration!

To edit the configuration, just edit the cfg file. To remove it, just remove the file from the folder.

Conclusion

File install is definitely a great tool to provision your system. The configuration admin supports can be useful to create iPOJO applications “on the fly” and will allows you reconfiguring your system dynamically!

Back from Amsterdam

2009-03-29T12:52:00.001+02:00

So, I’m back from ApacheCon. It was a great conference with high quality talks. OSGi was really a hot topic.

I organized an Apache Felix BOF with Felix, Carsten and Marcel. 30 people attend this BOF. This definitely illustrates the OSGi wave. I posted a BOF report on the Felix dev mailing list.

Another surprise is the feedbacks I get about junit4OSGi. It definitely seems to be the missing piece in OSGi development! So, my goal is now to release it soon (April). I recently improved the doc (now available from the iPOJO web site).

I have a couple of ideas about junit4osgi evolution. I will work on a better maven integration (site generation), in a way to do in-container tests, supporting other test ‘frameworks' such as junit4 or testNG… My discussions about these leads with junit4osgi users definitely interest them. So, here we go!

To summary ApacheCon in three words: “it was awesome!”

ApacheCon EU / EclipseCon

2009-03-16T11:48:00.003+01:00

The next week, I will be at ApacheCon EU in Amsterdam from Wednesday to Friday. If you have questions about iPOJO, pervasive or mobile applications, or if you just want to drink a beer, feel free to contact me.

If you prefer the sunny California to Amsterdam, Karl Pauls and Richard Hall will be at EclipseCon. Don’t hesitate to ask them iPOJO related questions. Moreover, do not miss their "OSGi in Action" tutorial.

Maven, OSGi, and native libraries on Mac OS

2009-03-06T11:10:00.000+01:00

I’m currently involved in a project dealing with native library. As a software engineering fan, I decide to set a project containing both unitary tests and integration test (thanks to the maven-junit4osgi-plugin, of course ☺).

However yesterday a strange issue appeared. The integration tests using the native library were executed “successfully”, but when I ran the same bundles in our application, I get UnsatisfiedLinkError. For all of you that already meet this Exception, it is always a bad thing.

What really does it means? No native libraries match with the actual architecture/os/… or if one matches it cannot be loaded for an obscured reason.

Hum, but I ran junit4osgi and the regular application on the same machine, my Mac book pro with Mac OS X! So, why junit4osgi was able to load the library and not a normal Felix platform (using exactly the same bundles)?

It takes at least 3 hours of debugging to understand what happened. First, I claimed against Maven ☺ (as everyday!), but in fact Maven was not guilty (just a little bit, because it is Maven). I also tried the application on Felix and Equinox. Despite Equinox was a little more verbose on the issue, the library was not loaded. I try different version of Felix, and always the same error: UnsatisfiedLinkError ! The worst thing happened when one of my co-worker executed the application on Windows correctly!

WTF????

Junit4OSGi test reports contain the system properties, and so I decided to compare the properties between junit4osgi and the normal runtime. And here arrived the light: maven and the runtime does not use the same JVM.

The OS provides the ‘mvn’ executable.
Clement-Escoffier:integration-test clement$ which mvn
/Users/clement/dev/apache-maven-2.0.9/bin/mvn

This executable uses Java 5 (the default JVM on Mac). So when running maven-junit4osgi-plugin, it uses this 32bits VM. In this context, the native library was loaded correctly.

However, when I ran the application, I use a Java 6 VM (64bits architecture). In this case, the library cannot be loaded. Despite it match the native library clause of my bundle; the library was not compiled to run on a 64bits CPU.

So finally, three hours spend for just a JAVA_HOME issue…

iPOJO available on Module Fusion

2009-02-23T09:11:00.001+01:00

Module Fusion is an OSGi based stack for enterprise applications. The goal of ModuleFusion is to help programmers to use the OSGi Service Platform as their underlying runtime environment.

ModuleFusion contains a full stack typical for Java enterprise applications. This stack currently consists of best-of-breed open source frameworks from the Java ecosystem. Additionally, ModuleFusion contains the necessary glue code to easily use these frameworks within OSGi.
Probably the most important principle of ModuleFusion is to base every integration, glue code and additional functionality on pure OSGi constructs. Therefore, ModuleFusion does not rely on proprietary features offered by some OSGi framework implementations.

The last week, I discuss with Roman about the possibility to integrate iPOJO in Module Fusion. So, now you can get an iPOJO feature pack, containing:

iPOJO 1.2.0
The ‘arch’ command
The temporal dependency handler

You can also get some examples about how to use iPOJO in Module fusion. More specially, a complete example about how using JPA (Hibernate) with iPOJO is provided.

For iPOJO early adopter using iPOJO 1.3.0-SNAPSHOT, a Wicket web application using iPOJO dependencies injection is also provided. This is for early adopter only because of the Felix-936 feature. This new feature is used to exposed the web application in the OSGi registry and so allows Pax:Web to publish it.

So, if you’re interested in OSGi on the server side, or on domain-specific OSGi based application servers, have a look to Module Fusion and see how iPOJO can help you in your daily development tasks.

Code coverage of OSGi applications

2008-12-09T18:31:00.003+01:00

The question that disturbs me last night is about test quantity/quality. So, when I can say: « Ok, I’ve enough tests ». So, for sure, this question is open.

Freddy Mallet posted a comment on my last post about Sonar. Sonar (http://sonar.codehaus.org/) is an all-in-one code quality tracker. So, based on maven (and a set of plug-ins), it collects data about your code, tests … and assembles reports on one web site with useful metrics (efficiency, usability…).

I tested today and was really impressed. But, my code coverage metrics was desperately 0 ☹
After some web searches, I found the Cobertura maven plug-in (http://mojo.codehaus.org/cobertura-maven-plugin/) collecting code coverage during test execution thanks to the Cobertura framework (http://cobertura.sourceforge.net/). However, as my systems and applications are tested in an OSGi container with junit4osgi, I investigated how to collect the code coverage of tests executed with juni4osgi.

So, first it is possible after a very small hack of junit4osgi to manage cobertura packages.
Collecting the code coverage is a three-step process:

A] Creates a bundle with instrumented classes
First you need to select ONE project under test. You will collect metrics on this project. So you want several projects, you need to execute the process several times (one per project).
Once selected, edit the pom file to ignore the ‘net.sourceforge.cobertura.* packages such as in:



  org.osgi.framework;version=1.3,
  org.osgi.service.cm,
  org.osgi.service.log,
  !net.sourceforge.cobertura.*

Then, execute the following command to create the instrumented bundle:

mvn clean install cobertura:instrument package install

This command creates the bundle with the Cobertura instrumented code, and installs it in the local maven repository. Moreover, it creates a file containing code metadata in the target/cobertura folder (cobertura.ser).

B] Test execution
Once the bundle is created, you need to execute the test. The code coverage is computed during this execution. So to launch the execution, go in your integration-test project and execute the following command:

mvn clean integration-test
  -Dnet.sourceforge.cobertura.datafile
      =/path/to/your/tested/project/target/cobertura/cobertura.ser

The ‘net.sourceforge.cobertura.datafile’ property specified the location of the cobertura.ser file (created during the Cobertura code instrumentation).

Tests are executed normally… But when maven is stopping, two messages appear:

Cobertura: Loaded information on 81 classes.
Cobertura: Saved information on 81 classes.

This means that the metrics were correctly collected.

C] Generation of the report and analysis of the code coverage
Once collected, go back to your tested project. To generate the report, just launch the following command:

mvn cobertura:cobertura

The report is generated in the target/site/cobertura/ folder. Here is an example of generated report. You can also check your code coverage with:

mvn cobertura:check

This doesn’t create the report but just gives an idea of the code coverage. You can use the cobertura plug-in configuration to adapt the checking or the report to your requirements.

That’s it.

Reducing the pain of a release process

2008-12-06T14:48:00.004+01:00

Who never crack down during a release process? Despite several tools ease the process; it’s generally a nightmare.

Why? Because of the number of task to execute during the process: the product has to be deeply tested before the release, then license/notice files have to be checked as well as license header, the release candidates artifacts have to be created, deployed, signed, don’t forget the release note, and to update the documentation…

So, I recently discover two maven plug-ins reducing (a little) the pain. They automate two checks: license headers and the code style consistency.

First the checkstyle plug-in (http://maven.apache.org/plugins/maven-checkstyle-plugin/) checks that your code is consistently formatted. It is, in my opinion, a critical aspect. So, diving into an unknown code consistently formatted is really easier. Using the plug-in is quite simple. Add the following plug-in configuration in the build section of your pom file:


<plugin>
<groupid>org.apache.maven.plugins</groupid>
    <artifactid>maven-checkstyle-plugin</artifactid>
    <configuration>           
        <enablerulessummary>false</enablerulessummary>
        <violationseverity>warning</violationseverity>
        <configlocation>http://felix.apache.org/ipojo/dev/checkstyle_ipojo.xml</configlocation>
    </configuration>
</plugin>

The ‘violationSeverity’ attribute sets the severity level from which the project build failed. So, if the code format breaks a rule with a level superior or equals to the set value, the build process failed. (Check levels can be set in the checkstyle file). The ‘configLocation’ attribute specifies the checkstyle file to use (containing the format rules).

So, once your project has the correct configuration, just launch the following command:

mvn checkstyle:check

to check if your project doesn’t break your format. If executed on a multi-module project, each module is checked (each module need to be configured).

So, thanks to this plug-in, checking the code format consistency is quite simple and can be automate during your project build process.

The second plug-in is the RAT plug-in (http://mojo.codehaus.org/rat-maven-plugin/). RAT (http://incubator.apache.org/rat/), is a tool to improve accuracy and efficiency when checking releases. It is heuristic in nature: making guesses about possible problems. It will produce false positives and cannot find every possible issue with a release. It reports require interpretation, but can also be automated…

In fact, RAT checks license header and tacks missing license. RAT provides a maven plug-in which can automate the missing license discovery during your build project. To use this plug-in, just add the following plug-in configuration in the build section of your pom file.


<plugin>
<groupid>org.codehaus.mojo</groupid>
<artifactid>rat-maven-plugin</artifactid>
<configuration>                
    <excludesubprojects>false</excludesubprojects>         
    <useeclipsedefaultexcludes>true</useeclipsedefaultexcludes>    
    <usemavendefaultexcludes>true</usemavendefaultexcludes>
    <excludes>
        <param>doc/**/*</param>
        <param>maven-eclipse.xml</param>
        <param>.checkstyle</param>
        <param>.externalToolBuilders/*</param>
        <param>LICENSE.*</param> 
        <param>.fbprefs</param>
    </excludes>
</configuration>
</plugin>

This configuration will check that non-excluded files have a correct license header. It excludes maven files (target folder), eclipse files (.project, .classpath). Those files don’t require a license, as they should not be on the source code repository. Then, others files can be excluded such as the doc folder (containing html files and release notes, used license files (LICENSE. *)... Extend the list (or modify it) according to your project.

To check that you have no file without a license header, just execute the following command:

mvn rat:check

The command failed if a corrupted file is detected. Executed on a multi-module project (each module need to be configured), it checks every module and failed as soon as a module has an invalid file.

So, by using these plug-ins, you can continuously check the consistency of your code format and of the license headers. This is not wonderful, but at least do one’s share of the work.

22.7 Mb!

2008-11-24T12:17:00.005+01:00

Today, all began perfectly.
I moved the junit4osgi plug-in to the iPOJO Trunk and decided with junit4osgi users to move the junit4osgi projects as ‘iPOJO top level’ project. And, icing on the cake, I finished my PHD Defense slides.

Moreover, I was pretty proud of my new script checking iPOJO current trunk:


mkdir tmp
cd tmp
svn co https://svn.apache.org/repos/asf/felix/trunk/ipojo
cd ipojo
mvn clean install -Pexamples,tests
mvn rat:check
mvn checkstyle:check
cd tests
cd integration-tests
mvn clean integration-test
mvn org.apache.maven.plugins:maven-surefire-report-plugin:report
/usr/bin/osascript -e 'tell application "Safari" to activate open location "file:/Users/clement/tmp/ipojo/tests/integration-tests/target/site/surefire-report.html"'

However, I executed it from scratch (empty maven repository), and here arrives the issue …
22.7 Mb is the size of my maven repository after the execution of the script ! It just downloads and compiles iPOJO trunk (not the whole Felix project) and executes tests.

After a quick analysis, some artifacts were downloaded in multiple versions. So, it’s time for me to track some of these artifacts, and to try to reduce this size. I’m pretty sure, that I can’t drastically reduce this mess, anyway, I’ll try.

Here are the duplicated artifacts:


commons-collections-2.1.jar
commons-collections-3.2.jar
commons-logging-1.0.3.jar
commons-logging-1.0.4.jar
commons-validator-1.1.4.jar
commons-validator-1.2.0.jar
org.osgi.compendium-1.0.0.jar
org.osgi.compendium-1.2.0.jar
org.osgi.core-1.0.0.jar
org.osgi.core-1.0.1.jar
org.osgi.core-1.2.0.jar
org.osgi.foundation-1.0.0.jar
org.osgi.foundation-1.2.0.jar
doxia-core-1.0-alpha-10.jar
doxia-core-1.0-alpha-8.jar
doxia-decoration-model-1.0-alpha-10.jar
doxia-decoration-model-1.0-alpha-11.jar
doxia-decoration-model-1.0-alpha-8.jar
doxia-site-renderer-1.0-alpha-10.jar
doxia-site-renderer-1.0-alpha-8.jar
maven-archiver-2.0.jar
maven-archiver-2.2.jar
maven-archiver-2.3.jar
maven-artifact-2.0.jar
maven-artifact-2.0.7.jar
maven-artifact-manager-2.0.jar
maven-artifact-manager-2.0.7.jar
maven-model-2.0.jar
maven-model-2.0.7.jar
maven-plugin-api-2.0.jar
maven-plugin-api-2.0.7.jar
maven-profile-2.0.jar
maven-profile-2.0.7.jar
maven-project-2.0.jar
maven-project-2.0.7.jar
maven-repository-metadata-2.0.jar
maven-repository-metadata-2.0.7.jar
maven-jar-plugin-2.1.jar
maven-jar-plugin-2.2.jar
maven-plugin-plugin-2.3.jar
maven-plugin-plugin-2.4.1.jar
maven-surefire-plugin-2.3.jar
maven-surefire-plugin-2.4.2.jar
maven-reporting-impl-2.0.jar
maven-reporting-impl-2.0.4.jar
maven-reporting-impl-2.0.4.1.jar
surefire-api-2.3.jar
surefire-api-2.4.2.jar
surefire-booter-2.3.jar
surefire-booter-2.4.2.jar
wagon-provider-api-1.0-alpha-5.jar
wagon-provider-api-1.0-beta-2.jar
plexus-archiver-1.0-alpha-3.jar
plexus-archiver-1.0-alpha-7.jar
plexus-archiver-1.0-alpha-9.jar
plexus-container-default-1.0-alpha-8.jar
plexus-container-default-1.0-alpha-9-stable-1.jar
plexus-i18n-1.0-beta-6.jar
plexus-i18n-1.0-beta-7.jar
plexus-utils-1.0.4.jar
plexus-utils-1.1.jar
plexus-utils-1.4.jar
plexus-utils-1.4.1.jar
plexus-utils-1.4.4.jar
plexus-utils-1.4.5.jar
plexus-utils-1.4.7.jar
plexus-utils-1.4.9.jar
plexus-utils-1.5.1.jar
plexus-velocity-1.1.2.jar
plexus-velocity-1.1.3.jar
plexus-velocity-1.1.7.jar
oro-2.0.7.jar
oro-2.0.8.jar

maven-junit4osgi-plugin

2008-11-11T09:59:00.011+01:00

Update: the junit4osgi artifact has recently changed. The groupID became org.apache.felix. Moreover, the plugin is now in the iPOJO trunk.

In my last post, I explain the advantages of integrating integration test in the build process. However, such tools was inexistent until … now ☺

As I explained, the junit4osgi framework allows testing an OSGi applications with a "junit++" framework (i.e. an adapted junit distribution providing useful methods to handle easily OSGi specific features such as services).

But, the junit4osgi framework is a “standalone” framework and is not integrated in a build tools such as Ant or Maven. This post describes a maven plug-in, maven-junit4osgi-plugin, executing tests in a maven-based build process.

Constraints of such tools
Providing such front-end is useful but should meet some requirements:
Tests are executed “in container”. So, tested bundles are really deployed on an OSGi framework (I choose Apache Felix). So tests are executing in an execution environment close to the final (production) execution environment. The goal of integration tests is to test the application in a production-like environment.

The project under construction is not a functional bundle, but can either be empty or contain integration tests. Integration tests are not placed in the same project as the project under test. Integration tests are packaged inside others bundles deployed on the same framework as the application under test..
To recreate the “final” execution environment, several bundles can be required (technical services, the application under test…). So the plug-in must support the deployment of required bundles.
Test results must be reported to the user. Maven provides an infrastructure to create web site. Moreover, Surefire (the Maven “regular” test plug-in) provides a plug-in generating a web page with test result. The provided plug-in should provide the same features and should reuse the same format as Surefire.

The good news is that the provided plug-in, maven-junit4osgi-plugin, match these requirements!

What does the maven-junit4osgi-plugin provide?

Allows testing OSGi applications
Integrated in a Maven-based build process
Provides the same output as Surefire
Supports Maven site generation

Using the plug-in

Download and building the plug-in
The plug-in sources are available in the iPOJO trunk.
However the junit4osgi and iPOJO runtime are also required. So, download the source of iPOJO:

svn co http://svn.apache.org/repos/asf/felix/trunk/ipojo/

To compile it, run the following commands:

cd ipojo
mvn clean install –Pexamples

(the –Pexamples allows compiling iPOJO examples and so the junit4osgi framework ans the plug-in). Now you can use the plug-in in your project.

Simple configuration
So, first the project using the plug-in is not the project under test. It’s another project containing either only integration-test packaged in a bundle, or is empty (and so depends on other bundles containing integration tests).
Tests contained in the project are developed with junit4osgi, and are packaged in a bundle with the maven-bundle-plugin.
In the pom file, add the following plugin configuration to use the maven-junit4osgi-plugin:


<plugin>
<groupid>org.apache.felix</groupid>
<artifactid>maven-junit4osgi-plugin</artifactid>
<executions>
<execution>
<goals>
      <goal>test</goal>
</goals>
<configuration>
<deployprojectartifact>true</deployprojectartifact>
</configuration>
</execution>
</executions>
</plugin>

Plugin parameter
The plug-in has only one parameter. The 'deployProjectArtifact' parameter enables or disables the current artifact deployment. If the current project contains tests, the plug-in can deploy the built artifact (as illustrated in this pom). Otherwise, the current project artifact is not deployed. This can be useful if the project just depends on other test bundles and sets the test configuration (as this pom).

Configuring the set of bundles to deploy
There is two different ways to configure the plug-in to deploy other bundles. If the bundle to deploy is a maven artifact, just add this artifact as a maven project dependency and set the dependency scope to ‘test’. Here is an example:


<dependency>
<artifactid>tests.manipulation.metadata</artifactid>
<groupid>ipojo.tests</groupid>
<version>1.1.0-SNAPSHOT</version>
<scope>test</scope>
</dependency>

If your bundle is not a maven artifact, you can configure the plugin with the bundle URL (from where the bundle will be deployed)


<configuration>
<deployprojectartifact>true</deployprojectartifact>
<bundles>
<param>file:/Users/clement/bundles/test-metadata.jar</param>
</bundles>
</configuration>

Set bundles are installed and started. You can depend on bundle that does not contain test as well as bundle containing tests.

Executing the plug-in
To execute test, just launch the ‘mvn clean integration-test’ command.


[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building iPOJO Primitive Manipulation Test Suite
[INFO]    task-segment: [integration-test]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [bundle:bundle]
[INFO] [ipojo:ipojo-bundle {execution: default}]
[INFO] Start bundle manipulation
[INFO] Metadata file : /Users/clement/Documents/workspaces/felix-trunk/ipojo/tests/manipulator/primitives/target/classes/metadata.xml
[INFO] Input Bundle File : /Users/clement/Documents/workspaces/felix-trunk/ipojo/tests/manipulator/primitives/target/tests.manipulation.primitives-1.1.0-SNAPSHOT.jar
[INFO] Bundle manipulation - SUCCESS
[INFO] [junit4osgi:test {execution: default}]
Analyzing org.apache.felix.ipojo - compile
Analyzing org.apache.felix.ipojo.metadata - compile
Analyzing org.osgi.core - compile
Analyzing junit - compile
Analyzing org.apache.felix.ipojo.junit4osgi - compile
Analyzing tests.manipulation.metadata - test

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Deploy : /Users/clement/Documents/workspaces/felix-trunk/ipojo/tests/manipulator/primitives/target/tests.manipulation.primitives-1.1.0-SNAPSHOT.jar
Loading org.apache.felix.ipojo.test.scenarios.manipulation.ManipulationTestSuite
Loading org.apache.felix.ipojo.test.scenarios.manipulation.ManipulationTestSuite
Junit Extender starting ...
Running Manipulation Metadata Test Suite
Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 0 sec
Running Primitive Manipulation Test Suite
Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 0 sec

Results :

Tests run: 33, Failures: 0, Errors:0

Unload test suites [class org.apache.felix.ipojo.test.scenarios.manipulation.ManipulationTestSuite]
Unload test suites [class org.apache.felix.ipojo.test.scenarios.manipulation.ManipulationTestSuite]
Cleaning test suites ...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6 seconds
[INFO] Finished at: Mon Nov 10 21:30:21 CET 2008
[INFO] Final Memory: 9M/18M
[INFO] ------------------------------------------------------------------------

Failures and errors are reported in the plugin output.

Generating the report web page
When test are executed, the plug-in generates XML reports (int the target/junit4osgi-reports directory) using the same convention as Surefire. So, it is possible to configure Surefire to generate the web page with test results.
To do this, add the following report configuration to the project executing tests:


<reporting>
<plugins>
<plugin>
<groupid>org.apache.maven.plugins</groupid>
<artifactid>maven-surefire-report-plugin</artifactid>
<version>2.4.3</version>
<configuration>
<showsuccess>true</showsuccess>
<reportsdirectories>
  <param>target/junit4osgi-reports</param>
</reportsdirectories>
</configuration>
</plugin>
</plugins>
</reporting>

This snippet configures the maven-surefire-report-plugin to collect results from the ‘target/junit4osgi-reports’ directory.
Then execute the plugin with the following command:

mvn org.apache.maven.plugins:maven-surefire-report-plugin:2.4.3:report

This command generates the web page with test results in ‘target/site’. This page shows an example of page generated with this command.

Plug-in design
The plug-in is quiet simple, it just starts an embedded Felix with a special activator installing and starting the junit4osgi framework and specified bundles.

Then, before executing test, the plug-in waits for “stability”. Indeed, as bundle activation can be asynchronous, the plug-in need to wait that the configuration is stable. Stability is obtained when all bundles are activated, and no new services appear or disappear on a 500 ms period. If after several second the stability cannot be reached, the plug-in stops.

Once the stability is reached, the junit4ogsi runner service is used to execute tests. Then results are collected and reports are generated.

Conclusion
This post has presented a front-end automating the execution of junit4osgi tests. Now it is possible to integrate OSGi application tests in a build process. The presented maven plugin provides following features:

An easy integration in a Maven-based build process
A good flexibility allowing reproducing production execution environments to test the application
Test result output is the same as surefire
Is able to generate Surefire-like reports

Lessons learned from iPOJO testing process

2008-11-02T18:33:00.006+01:00

Recently, we ask me several times if iPOJO is tied to the Felix runtime (i.e. works only on Felix). So, the answer is simple:

iPOJO relies only on the OSGi 4.1 specification, and so can work on any compliant implementation.

This post just explains how iPOJO is currently tested, and reflexion on OSGi application testing.

Test, Test and Test...

So, why testing?
Just because I'm very clumsy, and I can't guaranty that a patch don't have side effects broking a features. So, my tests aims to check that features still works and that I don't broke everything... That's why I developed junit4osgi at the same times as iPOJO. Before this improvement, testing iPOJO takes something like a working day! (now, it's close to 3 minutes...)

The iPOJO testing process weekly executed on three different OSGi implementations:

"Tested" means that the test suite is executed successfully on each implementation. This is done thanks to the junit4OSGi framework compatible with those implementations.
The test suite is also executed on different VMs such as Mika, JamVM and JRockit. Those tests are twofold:

Checks that the iPOJO framework can be executed on different VMs.
Checks that the iPOJO manipulation process generates consistent bytecode.

The second point is important, as the VMs are more or less tolerant to some mistakes ☺. Specially, Sun VMs are very tolerant!

So, let’s back to the testing process. The iPOJO test suite checks the most part of the iPOJO’s features. The iPOJO trunk contains a lot of test cases executed with the junit4osgi framework. Executing the test suite is quite simple: launch the OSGi implementation, launch the junit4osgi framework, deploy tests and finally use a front end (command line, GUI) to run tests.

Simple, isn’t it? However, during the development of the test suite, several issues appears:
- Handling asynchronous interactions
- Integrating test in the building process

Issues to test OSGi Applications

Testing services and their behavior is really easy with junit4OSGi. However, it becomes trickier when services realize asynchronous actions (i.e. actions are executed in a different thread and so not sequentially).

OSGi proposes an execution platform where a lot of actions are made asynchronously. Testing this kind of interaction is difficult, and generally requires magic waiting time.

For example, imagine a test pushing a configuration inside the configuration admin. The test creates a new configuration, pushes it to the configuration to the configuration admin, and checks that the configuration is correctly applied. However, the configuration admin applies the configuration in another thread. So the test must wait before checking that the configuration is correctly applied. Waiting is admitted, but how much time? Choosing a default time is rarely is good choice because it greatly depends on your configuration… Setting a long duration implies a long executing time…

So, you can argue that the Configuration Admin provide mechanisms notifying when configurations are correctly processed. That’s great, and the OSGi specification defines similar mechanisms for the most part of asynchronous interactions. So it should be possible to wait for this notification (or eventually throws a timeout).

However, if the ManagedService or the ManagedServiceFactory to update is not available, the notification is fired immediately, and is no more fired once the service arrives (at least on the Felix Configuration Admin). So, in this case you have to wait for an arbitrary time ☹. I’m looking for a better solution, but right now it still obscures to me how to handle those interactions cleanly.

The second issue with junit4osgi is very different. Executing tests are easy but I’m very (very) lazy. So, integrating those tests inside my build process could be great. An Ant task or a Maven plug-in could execute those tests automatically and react according to the results (if a failure or an error is detected, the build process fails). This automation can be easily implemented. It just requires starting an OSGi implementation, deploying the junit4osgi framework, starting required bundles as well as bundles containing tests and launching the test execution. It exist testing framework doing this, but they are generally usable only inside the build process and so lacks of flexibility. It must be possible to execute test manually on non-standard configurations. I’m going to implement a simple Ant task doing this. I’ll keep you posted…

iPOJO 1.0.0 and the future

2008-10-25T13:15:00.002+02:00

I recently released the version 1.0.0 of the iPOJO framework. This release is a major milestone for iPOJO.

iPOJO was created two years ago in the continuation of the Service Binder effort. The initial goal was to provide an easy way to create dynamic service-based applications on the top of OSGi without losing the OSGi philosophy (small, universal middleware).
At the same time, I was involved in several projects where I realized that iPOJO must focus on different goals:

Must be simple… (Avoids redundancies, provides annotations)
Must be extensible to tackle specific requirements
Must provide a way to design applications

The first requirement comes from the OSGi development model. OSGi is very powerful, but the learning curve is slow and long. A lot of mechanisms (mostly about class loading and threads) must be understood. Hiding or simplifying those mechanisms was a stringent requirement.

The first project using iPOJO was the design and the implementation of a residential gateway. However, we quickly understood that developing such kind of application requires some specific technical services such as a MOM allowing event-based interactions, a scheduler (i.e. Cron) to automate periodic task triggering, a way to administrate applications remotely… Providing such technical services is not too difficult. However, automating the interaction with those technical services was more challenging. From this observation, we decide to provide an extension mechanism allowing adding such kind of features without modifying the core of the project. So, iPOJO can be small as well as providing a lot of functionalities.

Finally, we realize that we need a way to design applications. Traditional ways to design applications are somewhat limited. Generally they are limited to static applications (with no possible evolution at runtime) and the architecture description is lost just after that the application is deployed. After a long work with Richard S. Hall, we propose and implement a new way to design applications on the top of OSGi. iPOJO composite allows isolating services, support dynamism … This is the most innovative part of the iPOJO project.
The iPOJO 1.0.0 release is the result of these two years of development, research, interrogations and experimentations. The iPOJO framework is composed by:

A core system providing basics functionalities (requiring/providing services, lifecycle, instance introspections…)
A full integration with the Configuration Admin
A way to design and execute dynamic applications
Several external handler extending core capabilities with JMX administration, Event Admin interactions, Temporal service dependency, whiteboard and extender patterns …

The future of iPOJO is also exciting. With the support of my ‘future former’ group, extensions such as distribution and deployment are under development. The distribution framework allows iPOJO instances to interact with remote services (using any protocol) and can be exposed remotely. The deployment support computes OBR descriptions from metadata providing features easing the deployment. Improvements such as providing a control and creation API are also investigated. The future version will see the arriving of new ‘handlers’ handling persistence and scheduling as well as a better integration with the junit4osgi framework.

All those stuffs are really promising… Isn’t it?

iPOJO on Android

2008-10-21T15:38:00.024+02:00

Android is the Google OS for mobile phone (and the future GPhone). Android provides a Java-like virtual machine: Dalvik.

So, why not trying to execute an iPOJO-based application on the top of Android?
The idea was to embed an OSGi/iPOJO framework on Android and then to deploy an application on the top of the framework.

You can download the application in two parts:
the Android application embedding Felix/iPOJO : here
the SpellChecker application : here

The application is designed as follow:

The Android application creates and starts a OSGI/iPOJO framework (Felix + iPOJO + FileInstall)
The Android application tracks a ViewFactory service. This service is used to display the application GUI (the service allows creating the GUI main component).
The SpellChecker application (10 minutes tutorial) is deployed on OSGi, and use iPOJO. The only difference with the one form the 10 minutes tutorial is the GUI that uses Android HMI component (rather than Swing)

SpellChecker application bundles are deployed thanks to FileInstall. A specific folder is monitored in order to install/update/uninstall jar files contained in this folder.

Embedding Felix and iPOJO inside an Android Application

First, we need to create an Android application. This application creates a new Felix when the application is instantiated:


public synchronized void onCreate(Bundle icicle) {
super.onCreate(icicle);
setContentView(R.layout.main);
PrintStream out = new PrintStream(new OutputStream(){
ByteArrayOutputStream output = new ByteArrayOutputStream();
@Override
public void write(int oneByte) throws IOException {
  output.write(oneByte);
  if (oneByte == '\n') {
    Log.v("out", new String(output.toByteArray()));
    output = new ByteArrayOutputStream();
  }
}});
System.setErr(out);
System.setOut(out);
m_configMap = new StringMap(false);
m_configMap.put(FelixConstants.LOG_LEVEL_PROP,String.valueOf(Logger.LOG_DEBUG));
m_configMap.put(DirectoryWatcher.DEBUG, "1");
// Configure the Felix instance to be embedded.
m_configMap.put(FelixConstants.EMBEDDED_EXECUTION_PROP, "true");
File bundles = new File(FELIX_BUNDLES_DIR);
if (!bundles.exists()) {
 if (!bundles.mkdirs()) {
    throw new IllegalStateException("Unable to create bundles dir");
 }
}
m_configMap.put(DirectoryWatcher.DIR, bundles.getAbsolutePath());
// Add core OSGi packages to be exported from the class path
// via the system bundle.
m_configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES, ANDROID_FRAMEWORK_PACKAGES);
// Explicitly specify the directory to use for caching bundles.
try {
 m_cache = File.createTempFile("felix-cache", null);
} catch (IOException ex) {
 throw new IllegalStateException(ex);
}
m_cache.delete();
m_cache.mkdirs();
m_configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP, m_cache.getAbsolutePath());
}

When the application starts, the Felix Framework is started with two Activators :

one installing bundles from resources
one installing bundles from a folder (FileInstall)

Then a service tracker is used to track arrivals and departures of the ViewFactory (provided by the SpellChecker GUI).


public synchronized void onStart() {
super.onStart();
setContentView(new View(this));
Resources res = getResources();
try {
 List<BundleActivator> activators = new ArrayList<BundleActivator>();

 // Plugs the bundle installer (install bundle from application resources)
 activators.add(new Installer(res));
 // Plugs the FileInstall activator
 activators.add(new FileInstall());

 m_felix = new Felix(m_configMap, activators);
 m_felix.start();
} catch (BundleException ex) {
 throw new IllegalStateException(ex);
}
try {
 m_tracker = new ServiceTracker(m_felix.getBundleContext(),
  m_felix.getBundleContext().createFilter("(" + Constants.OBJECTCLASS
      + "=" + ViewFactory.class.getName() + ")"),
      new ServiceTrackerCustomizer() {

      @Override
      public Object addingService(ServiceReference ref) {
          System.out.println("======= Service found !");
          final ViewFactory fac =
             (ViewFactory) m_felix.getBundleContext().getService(ref);
          if (fac != null) {
              runOnUiThread(new Runnable() {
                   public void run() {
                      setContentView(fac.create(ApacheFelix.this));
                  }
              });
          }
          return fac;
      }

      @Override
      public void modifiedService(ServiceReference ref,
              Object service) {
          removedService(ref, service);
          addingService(ref);
      }

      @Override
      public void removedService(ServiceReference ref,
              Object service) {
          m_felix.getBundleContext().ungetService(ref);
          runOnUiThread(new Runnable() {
              public void run() {
                  setContentView(new View(ApacheFelix.this));
              }
          });
      }});
m_tracker.open();
} catch (InvalidSyntaxException e) {
 e.printStackTrace();
}
}

Note that the iPOJO bundle is deployed from application resource. The bundle was “dexed” and placed in the res/raw folder of the application project. Then, you can load the bundle with:


public void start(BundleContext arg0) throws Exception {

InputStream is = res.openRawResource(R.raw.ipojo);

Bundle bundle = arg0.installBundle(IPOJO_HTTP_PATH, is);
bundle.start();
}

Before the be installed, the application must be exported in a .apk file.
SpellChecker application
The application is basically the same than the one form the 10 minutes tutorial. There are two differences:

Bundles are “dexed”
The GUI bundle is implemented with Android GUI components

Another difference is about the optionality of the dependency on SpellChecker service. This dependency is now optional, and use two bind/unbind methods:

public synchronized void bindSpellChecker(SpellChecker sp) {
checker = sp;


if (activity != null) {
activity.runOnUiThread(new Runnable() {
public void run() {
  // Enable button
  m_button.setEnabled(true);
  m_result.setText("Enter words, and click on 'check'");
  m_main.invalidate();
  System.out
          .println("==> Spell checker GUI receives
           a new spell checker ...");
}
});
}
}

public synchronized void unbindSpellChecker(SpellChecker sp) {
checker = null;
if (activity != null) {
activity.runOnUiThread(new Runnable() {
public void run() {
  // Enable button
  m_button.setEnabled(false);
  m_result.setText("No Spellchecker available");
  m_main.invalidate();
  System.out
          .println("=====> Spell checker GUI was
           unbind from the spell checker");
}
});
}

Note that GUI modifications MUST be done in the UI Thread.

Starting the emulator

The application uses a SD card storage. So creates an SDCard iso:


mksdcard size filename

Then, launch the emulator (emulator must be accessible from your path) with:


emulator -shell -sdcard dev/android/sdcard1.iso

The emulator starts. When the shell is ready, change the permission access on /data/dalvik-cache:


chmod 777 /data/dalvik-cache

These permissions are needed to correctly load bundles.

Installing the application

To install the application (the .apk file), I use the Eclipse plugin (the apk file can be unsigned) or with the adb command (the apk file must be signed).
Once signed, you can deploy your application with:


adb install application.apk

Once installed, the application is available in the Android emulator menu

If you launch the application, a black screen appears … The Spellchecker application is not deployed!
So, to deploy the application, the bundles files must be placed in the /data/felix/bundles folder.

adb push SpellCheckGui\ for\ Android.jar /data/felix/bundles/SpellcheckGui.jar gui.jar
cd bundles
adb push spell.services.jar /data/felix/bundles/spell.services.jar

If you launch the application, the GUI appears, but you can’t use the check button. No spell checker services are available. Push the others jars in the same folder.

adb push spell.checker.jar \
/data/felix/bundles/spell.checker.jar
adb push spell.english.jar \
/data/felix/bundles/spell.english.jar

Once done, the check button becomes available. If you remove a the English dictionary, the check button becomes disabled:

adb shell rm /data/felix/bundles/spell.english.jar
adb push spell.english.jar /data/felix/bundles/spell.english.jar

Conclusion

This very simple application has shown that it is possible to create dynamic applications on the top of Android with OSGi and iPOJO. It sounds really promising …

References