I am running an example JAVA Swing class that is accessing a REDHAWK backend via CORBA (jacorb). The example is an OSGi application. Inside of Eclipse, I run the project using an OSGiFramework run configuration. The application works as expected, communicating with the REDHAWK backend and popping up the Java Swing UI. I run the application outside of Eclipse using the config.ini and dev.properties files that was created by Eclipse. I get the following error with the command line arguments shown below. From the console I checked that the jacorb bundle was installed and active.
/usr/lib/jvm/java-1.7.0-openjdk/bin/java -jar ./org.eclipse.osgi_3.8.2.v20130124-134944.jar -dev file:dev.properties -os linux -ws gtk -arch x86 -application com.viper.swing.application -consoleLog -console
java.version=1.7.0_51
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
Framework arguments: -application com.viper.swing.application
Command-line arguments: -dev file:dev.properties -os linux -ws gtk -arch x86 -application com.viper.swing.application -consoleLog -console
!ENTRY org.eclipse.osgi 4 0 2014-03-21 10:38:58.446
!MESSAGE Application error
!STACK 1
java.lang.NoClassDefFoundError: org/omg/CORBA/Object
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClassHoldingLock(ClasspathManager.java:632)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:607)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:568)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:492)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:465)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
...
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.java:151)
Caused by: java.lang.ClassNotFoundException: org.omg.CORBA.Object at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ... 75 more
In standard OSGi environments, only the java.* packages are automatically imported into the bundle by the OSGi framework. All other packages need to be explicitly imported via an Import-Package statement in the manifest.
Especially eclipse/equinox is known to delegate class resolving of classes that normally come with the JRE to the standard VM classloader in its debug/run environment. This means that if you run bundles outside the eclipse environment, you get complaints about missing imports or some class not found exception.
The solution would be to either correct the imports or to adapt the outside environment to behave as if run within eclipse. The latter can be done by adding the following line to the configuration (i.e. configuration/config.ini):
org.osgi.framework.bootdelegation=*