dana-i2cat/opennaas — pull request #12 by gbehrmann (2012-01-25 15:42:17+00:00)
Title: Upgrade to latest release of FUSE ESB

Hi Isart,

I am certain you are aware of the annoying misfeature that the first startup of OpenNaaS always prints the welcome message twice, followed by a stack trace.

I found this quite annoying and tried to locate the source of the problem. I did locate it and think it is a bug in Karaf. The problem is triggered by a combination of

1. OpenNaaS relying on the OSGi compendium bundle
2. OpenNaaS being installed through the bootFeatures feature
3. The bootFeatures feature listing karaf-framework
4. Bundles in karaf-framework having an optional import on packages exported by the compendium bundle

What happens is that Karaf when loading a feature checks whether any of the required bundles are already installed - if so it doesn't need to install them again. It does however check whether any of those bundles have optional imports on other bundles part of the feature. If so it restarts the already installed bundle to resolve the optional dependency. It only does this for bundles part of the feature to install. Other bundles already installed are not subject to this check and are not restarted.

During boot when installing the bootFeatures Karaf however considers all bundles belonging to the boot features to belong together. This has a unfortunate side effect:

1. It builds a list containing bundles of karaf-framework and opennaas-core-deps
2. It sees that all the bundles of karaf-framework are already installed, so they are not installed again
3. Some of those bundles however have an optional import of opennaas-core-deps, so they are restarted
4. Among the restarted bundles are the console service (causing the repeated print of the welcome message) and the features admin; the latter is causing the stack trace. The stack trace happens because the feature admin is the one installing the boot features; when it gets restarted in the middle of installing the boot features, the bundle context becomes invalid and thus causes a stack trace to be printed.

The amazing thing is that if you install the opennaas feature manually after boot then the problem does not occur: This is because Karaf in that situation only looks at the bundles belonging to the opennaas feature and its dependencies. These don't include the console or feature admin, and thus those bundles don't get restarted (even though they have optional imports on the compendium packages).

In the end I think this is a Karaf bug. There are actually two bugs:

1. Karaf fails to save the state of the feature admin if the restart involves the feature admin itself
2. Karaf treats features installed manually one by one different from features installed through bootFeatures property

I will try to create a minimal example outside OpenNaaS, based on only Karaf, and submit a bug report upstream.

This branch I am asking you to pull upgrades OpenNaaS to the latest FUSE version. I was hoping the latest version would fix the bug. They did make changes to the boot features functionality (see the patch description), however the specific bugs I mentioned are unfortunately not fixed. The patch however includes a simple workaround: The default boot features of the new FUSE does not include karaf-framework (as it is installed by default in Karaf). This means we don't hit the problem.

Even though the core problem I tried to resolve wasn't fixed in the new version, I think it is worth upgrading to the latest version as it is a bug fix release.

Please note that the JPA change on feature/close-jpa-entitymanager is not included; depending on which change you merge first I will have to rebase the other branch before you can merge it.

Naturally the version numbers need to be incremented in Mantychore as well; I will submit a patch to you for doing do.

Cheers,

/gerd