OSGi bundle deployment and OpenGL

[GeneLege]

Has anyone sucessfully utilized the opengl rendering mode in an OSGi deployment of the sdk/jars?

This is important to us because we must support Linux as a platform, whcih requires the opengl render.  We have built an OSGi bundle of all of the jars in sdk/jars, and this works fine on Windows with the DirectX renderer,  But when you switch to the opengl render, the following types of errors are seen from jogl:


Caused by: java.lang.IllegalArgumentException: JAR URL doesn't start with 'jar:', got <bundleresource://11.fwk2094875182:6/com/jogamp/common/os/Platform.class>
                at com.jogamp.common.util.JarUtil.getJarSubURL(JarUtil.java:140)
                at com.jogamp.common.os.Platform$3.run(Platform.java:309)
                at java.security.AccessController.doPrivileged(Native Method)
                at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:303)
                at com.jogamp.common.os.Platform.<clinit>(Platform.java:214)

I googled this and found:

https://jogamp.org/bugzilla/show_bug.cgi?id=537

Which definitely seems to be related, but I think it is actually something different going on 

One comment on the bug report suggested "turning off USE_TEMP_JAR_CACHE", so I ran with
-Djoglamp.gluegen.UseTempJarCache=false, and then I started getting various UnsatisfiedLinkError exceptions.

I am peering into jogl more, but so far nothing is jumping out at me.

[GeneLege]

Just as a follow-up, I got this to work by:

1)  Packaging jogl.all.jar and gluegen-rt.jar as a separate plugin.  Additionally, I have a plugin for the rest of the non-native code jars in the sdk/jars directory.

2)  Implementing fragment bundles for the respective native code jars

3)  Setting the java property jogamp.gluegen.UseTempJarCache=false

When I tried to do the same thing, but with all the managed code in a single plugin, I ran into issues, but I now suspect I had made some other mistakes, as that should work, theoretically, as well.

What will *not* work is packaging up all of the jars in a single plugin.  This actually could be made to work, with a newer version of jogl, utilizing a mechanism that they have implemented to automate the selection/loading of the correct native code, but there is an interface incompatibility with those newer versions of jogl and the version that the ESRI Runtime SDK expects, so no go for now.

[EricBader]

Thank you, Gene.

One thing to note: we have removed jogl from the product at 10.2.

[CarlosColón-Maldonado]

we have removed jogl from the product at 10.2.

Interesting news, Eric. Not to get ahead of myself, but any ramifications to this decision, e.g., SDK users must now install OpenGL on their own, it's a new installation prerequisite, no longer required unless a specific functionality is need, Windows users must use DirectX without option, etc.?

[EricBader]

First, let me apologize for alarming anyone.
The jogl jars were not really being used for anything significant, and anyway we have relegated all of the opengl/directX rendering to the core native runtime. By removing the jars, we slim down the size of your app deployments a bit.

So we are not removing OpenGL support, nor will you have to do anything special for your app deployments to handle OpenGL, as long as OpenGL is already on the target machine.

Again, I am sorry for not providing a better context to my initial statement on this!

Thanks!

[CarlosColón-Maldonado]

No problem, Eric. It's good to know there will be less bundling for deployments.

[JohnWass]

I came across this older post and just wanted to make a note.  I have not done anything with OSGi, but it sounds similar to the problems I have recently overcome related to configuring the 10.1 runtime components in our maven environment. 

What will *not* work is packaging up all of the jars in a single plugin.  This actually could be made to work, with a newer version of jogl, utilizing a mechanism that they have implemented to automate the selection/loading of the correct native code, but there is an interface incompatibility with those newer versions of jogl and the version that the ESRI Runtime SDK expects, so no go for now.

Just as Gene noted above, the older jogl that Runtime uses will not work due to implementation details.  The key version appears to be 2.0-RC10, where the jogl native library unpacking implementation was changed.

The sweetspot I found for getting this to work through maven was to use version 2.0-RC11 of jogl and gluegen, both of which are still available on maven central.  The interface incompatibility is reduced at this point to only two jogl files in javax.media.opengl, GLContext and Threading.  By overriding those classes using the classpath and adding a couple method stubs in each it will work.

I have been running like this for a week now with no issues.  Jogl unpacks the libraries and modifies java.lib.path at runtime as expected.  Im sure you will get frowned at if you ask for support while doing this, but it will work if you are in my situation where you need to get integrated into something like maven and can wait for 10.2 for a production ready configuration.

I can provide the overridden jogl file diffs if needed, but they are pretty simple implementations.

hth

[StephenBaier]

Just as a follow-up, I got this to work by:

1)  Packaging jogl.all.jar and gluegen-rt.jar as a separate plugin.  Additionally, I have a plugin for the rest of the non-native code jars in the sdk/jars directory.

2)  Implementing fragment bundles for the respective native code jars

3)  Setting the java property jogamp.gluegen.UseTempJarCache=false

I followed suite with this tactic, as suggested not only here but in other places on the internet. However, I am still receiving linker exceptions, even after explicitly adding the jars to the classpath.

Currently I have one plugin, which is my "map" plugin, containing all jars except for gluegen and jogl jars; another plugin which contains the non-native jogl.all and gluegen-rt; and a linux specific plugin containing the jog.all-linux and gluegen-rt-linux jars. If I run without the UseTempJarCache=false, I receive the JAR URL expcetion; If I run with it, I receive the Linker exception.

Anyone have any insights into this? Developments since original post?

[GeneLege]

I followed suite with this tactic, as suggested not only here but in other places on the internet. However, I am still receiving linker exceptions, even after explicitly adding the jars to the classpath.

Currently I have one plugin, which is my "map" plugin, containing all jars except for gluegen and jogl jars; another plugin which contains the non-native jogl.all and gluegen-rt; and a linux specific plugin containing the jog.all-linux and gluegen-rt-linux jars. If I run without the UseTempJarCache=false, I receive the JAR URL expcetion; If I run with it, I receive the Linker exception.

Anyone have any insights into this? Developments since original post?

The fragment bundles should unpack the .so or .dll files to a location on the LD_LIBRARY_PATH (or the PATH for .dll's on Windows) - just wanted to make sure this is clear since you are having linker problems...

[StephenBaier]

It is worth mentioning that the original post has the wrong JVM argument. It is actually:

-Djogamp.gluegen.UseTempJarCache=false

The difference is subtle, the package is jogamp, not joglamp. This was messing me up a ton because I got back to a state where, even with the argument, I would get the JAR URL exception.

That being said, in response the previous post, I extracted the .so (I'm on Linux) files from the JARs manually and placed them in my Linux project fragment. This got me past the Linker exceptions and not-on-classpath exceptions. However, I am now on new grounds receiving this error:

javax.media.opengl.GLException: Profile GL2ES2 is not available on null

So that's my next avenue of chase.