Issues with start levels for gogo console bundles

Question

I just migrated an older OSGi project to the current equinox version (Kepler SR1). When using the gogo console I encountered a problem when starting the gogo bundles with start level 1 (that's what I usually do with all relevant framework bundles). The gogo console won't startup though all four bundles are active and running. Typing help would result in a NullPointerException. The solution is to start all gogo bundles with the default start level. Did I miss anything or is this just a case of bad design of the bundle lifecycle? Bundles should not depend on start levels in order to work.

Mike

Answer 1

I found the reason for the exception:

We are using some old style CommandProviders. There seems to be a bug in the equinox.console bundle when printing the help for the legacy commands. The set of legacyCommandProviders in the class org.eclipse.equinox.console.commands.HelpCommand seems to contain null-entries (for whatever reasons) which lead to the exception. This only occurs sometimes. Seems we need to convert our legacy commands... :-(

Answer 2

It's possible to run Equinox and have all bundles started with a start level of 1. Using the following start configuration works as expected:

<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -console -clean"/>
<stringAttribute key="target_bundles" value="org.apache.felix.gogo.command@1:true,org.apache.felix.gogo.runtime@1:true,org.apache.felix.gogo.shell@1:true,org.eclipse.equinox.console@1:true,org.eclipse.osgi@-1:true"/>

Bear in mind that Eclipse caches a lot of stuff with its product launches, and very often errors can creep in by virtue of the fact it doesn't get rid of the workspace between launches. This can sometimes cause errors like the one you've seen above. You can delete the launch configuration which will also clean the associated folders, then add it back in again afterwards.

To verify that this works as expected, create a new runtime configuration as an OSGi Framework and add the four bundles, with the start level 1 and autostart true.

Note that the org.eclipse.osgi bundle is the framework bundle, and should have a start level of -1 to indicate the default; perhaps that is the problem you're seeing.