JOGL with OSGi

Hi,

I'm trying the same to split JOGL and GlueGen into individual plugins using https://github.com/reficio/p2-maven-plugin. In addition I created fragments for GlueGen and JOGL for the individual platforms.

However, I have some class loading problems. The native libraries are bundled and specified in the OSGI manifest, but when I start my application I got an UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError: jogamp.nativewindow.windows.GDIUtil.initIDs0()Z

I debugged the code and it was successfully able to load the "nativewindow-win32.dll" library. But it seems to be that it will loaded in the wrong classpath. To be more precise, GDIUtil uses the JNILibLoaderBase class to load the library using System.load(.../nativewindow-win32.dll).

The problem is that System.load(...) will use the classloader of the caller class (= JNILibLoaderBase) to store the reference to the loaded library. But this class is part of the gluegen bundle. Therefore after the library was successfully loaded, it will created the java.lang.UnsatisfiedLinkError error, as the library was not loaded with the correct classloader (the one of GDIUtil  = jogl bundle classloader)

Has anyone an idea how to fix this? (besides bundling gluegen and jogl together)

btw: It would be great, if temp jar resolver (-natives-windows-amd64.jar thing) would be more handy and check different options, following maven (<base>-<version>-natives-windows-amd64.jar) and osgi syntaxes (<base>-natives-windows-amd64_<version>.jar)

Hi

We could modify JNILibLoaderBase .loadLibraryInternal() in order to perform the calls of System.load() in a method of a class in the right class loader but maybe it would cause some regressions. I'm not sure that my suggestion is safe.

I don't use Reficio but I succeeded in splitting JOGL and GlueGen into separate OSGI bundles several years ago at work and some other guys did it too (Wade, are you here?).

I would really be interested in the MANIFEST.MF files of those bundles.

Reficio p2-maven-plugin is just a small wrapper around bnd (http://www.aqute.biz/Bnd/Bnd), so there is no special magic coming with that tool.

btw. I'm using eclipse kepler with jogl version 2.0.2

gouessej wrote

I don't use Reficio but I succeeded in splitting JOGL and GlueGen into separate OSGI bundles several years ago at work and some other guys did it too (Wade, are you here?).

Sorry, I haven't tried splitting GlueGen and JOGL into separate bundles (since whenever I use one, I've always used the other). I'm sure it's possible, but it might take some careful refactoring to get the code to work that way.

samg, would it be acceptable for you to keep GlueGen and JOGL in the same bundle? Our bundles worked fine with JOGL RC8 but we had to disable the automatic extraction of native libraries, it wasn't a smart solution. You can't use JOGL with any version of GlueGen, putting them into the same bundle makes sense.

Wade, do you have an example of OSGI bundle for JOGL? I'm not allowed to disclose mine :s but it shouldn't be very difficult to do.

I can give it a try.

However, the basic underlying idea was that if I'm using JOGL + JOCL + JOAL together all of them need Gluegen. In the combined solution, I would have to bundle Gluegen into all of them, whereas in the splitted solution I would just to depend on the Gluegen bundle.

Best Regards
sam

You can make a single bundle with JOGL + JOCL + JOAL + GlueGen but I admit that if you want to make a bundle for each API, you'll have to put GlueGen into each bundle, i.e, JOGL + GlueGen, JOCL + GlueGen, JOAL + GlueGen.

I created now some packages where gluegen and jogl is combined into a single package (including sources and natives)

That works for the moment but it would be great if the class loading problem could be fixed in the future. As far as I understand it would just be to extract the System.load(...) and System.loadLibrary(...) call to some class, which is part of each bundle: jogl, jocl and joal, e.g. as part of the LoaderAction of JNILibLoader.

Btw. don't use the "uses:" osgi clause (http://blog.springsource.org/2008/10/20/understanding-the-osgi-uses-directive/). I took me around a day to find out why the combined gluegen and jogl, didn't work. The problem was that because of the uses clause, I again got some different classloaders.

So thanks for your help.

sam wrote

That works for the moment but it would be great if the class loading problem could be fixed in the future.

The problem is that GlueGen and JOGL haven't been designed to work in separate class loaders. You can see in the source code that it is possible to choose in which class loader to load them both but the class loader of JOGL will have to be a "son" of the class loader used by GlueGen. Actually, you might find some other blocking problems even with my suggestion.

sam wrote

As far as I understand it would just be to extract the System.load(...) and System.loadLibrary(...) call to some class, which is part of each bundle: jogl, jocl and joal, e.g. as part of the LoaderAction of JNILibLoader.

That's what I meant, feel free to test my suggestion which is very easy since my change to fix the bug 810.

hi,

one last note, if anyone needs it.

Someone may notices that if you depend on the SWT bundle you will automatically have your platform specific fragment in your resolved dependencies and classpath, too.

However if you create a plain fragment (e.g. the jogl natives) it won't be automatically added. The solution is to add the The Eclipse-ExtensibleAPI Header flag within your main plugin (e.g. jogl-all).

We just have to set it to true:
Eclipse-ExtensibleAPI: true