0

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

MikeR
  • 51
  • 5
  • Could you please post the piece of configuration where you actually set the start levels? – evandor Jan 03 '14 at 11:43
  • We war using eclipse product definitions. The specific part of the start levels is: ` ` – MikeR Jan 03 '14 at 13:05
  • However in a simple example everything works fine... It must be something special about my application settings. – MikeR Jan 03 '14 at 13:08
  • I am getting `osgi> help gogo: NullPointerException: null osgi> ` – MikeR Jan 03 '14 at 13:08
  • Not too much to work with ;)... One idea, which maybe could be helpful: add Felix Log (e.g. from http://www.eu.apache.org/dist//felix/org.apache.felix.log-1.0.1.jar) and check if you get any output in the shell when typing "log debug"... maybe the detailed gogo exception appears... what are your gogo versions by the way? What do you get when typing "ss"? – evandor Jan 03 '14 at 14:39
  • You're right that bundles shouldn't depend on start levels. Why are you even specifying them? I never (well, hardly ever) use start levels, and Gogo works just fine. – Neil Bartlett Jan 03 '14 at 22:22
  • Mostly I start the osgi framework bundles on level 1 and the rest of the application bundles on default level. "log debug" won't give any detailed information on the Nullpointer Exception. – MikeR Jan 06 '14 at 07:49

2 Answers2

0

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.

AlBlue
  • 23,254
  • 14
  • 71
  • 91
  • Unfortunatly setting the -1 level for org.eclipse.osgi does not help. The problem arises inside and outside of eclipse even with a fresh application start. – MikeR Jan 06 '14 at 07:44
0

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... :-(

MikeR
  • 51
  • 5
  • The reason is that one of our command providers gets active rather late. There is missing null pointer check in the HelpCommand class. – MikeR Jan 06 '14 at 09:10