Glad you got it running, Thomas. Yes on the sun.misc. For comparison purposes, in the maven pom for our
VWorld-bundle demo project artifactID:
org.friendularity.bundle.demo.ccmio
...when launching under felix OSGi container, we supply this key-value block of packages, starting with sun.misc
<!-- Friendularity customizations :
1) Allow sun.misc package to be used by LWJGL.
2) org.w3c.dom.* are wanteed by Jena, Xerces, (+?), and are missing from
default.properties in felix 4.2.1, tho they are present in 3.0.7 -->
<entry key="org.osgi.framework.system.packages.extra" value="sun.misc, org.w3c.dom.css, org.w3c.dom.html, org.w3c.dom.stylesheets, org.w3c.dom.traversal, org.w3c.dom.ranges, org.w3c.dom.views, org.w3c.dom.xpath" />
Regarding Thomas's question:
"...multiple issues with classloading and native code. Did you make changes
to the JME3 code published
Here is a rambly 5 part answer:
1) No changes to the JME3 code in ext.bundle.opengl.jmonkey.
It is just an OSGi-exporting wrapper-bundle for the JME3 artifacts.
Those JME3 artifacts are in Maven central repo, uploaded by me
and some other folks (in the era before JMonkey team published
maven artifacts.
Probably you have already seen the bnd instructions in that pom.xml file
Here is the link, and the crucial part is quoted below.
https://search.maven.org/remotecontent?filepath=org/cogchar/ext.bundle.opengl.jmonkey/1.1.4/ext.bundle.opengl.jmonkey-1.1.4.pomOur activator for this bundle just prints messages on .start() and .stop().
There may be a few packages that we did not export because their
transitive dependency closure was yucky, but it was a pretty minor
exclusion, I believe. (YMMV). However do note that all the "nifty" GUI
packages are handled by a separate wrapper bundle that has not been tested
in a few years.
<Bundle-Activator>org.cogchar.ext.bundle.opengl.jmonkey.OpenglJmonkeyBundleActivator
</Bundle-Activator>
<Import-Package>sun.misc, *;resolution:=optional</Import-Package>
<Export-Package>
com.jme3.*;-split-package:=merge-first, native.*, jme3tools.*;-split-package:=merge-first, org.lwjgl.*, com.bulletphysics.*, javax.vecmath.*, de.jarnbjo.*, Common.*, Interface.*
</Export-Package>
<Bundle-NativeCode>
native/linux/liblwjgl.so; native/linux/libjinput-linux.so; native/linux/libopenal.so; osname=linux; processor=x86, native/linux/liblwjgl64.so; native/linux/libjinput-linux.so; native/linux/libopenal64.so; osname=linux; processor=x86-64, native/windows/lwjgl.dll; native/windows/jinput-dx8.dll; native/windows/jinput-raw.dll; native/windows/OpenAL32.dll; osname=win32; processor=x86, native/windows/lwjgl64.dll; native/windows/jinput-dx8_64.dll; native/windows/jinput-raw_64.dll; native/windows/OpenAL64.dll; osname=win32; processor=x86-64, native/windows/lwjgl64.dll; native/windows/jinput-dx8_64.dll; native/windows/jinput-raw_64.dll; native/windows/OpenAL64.dll; osname=win10; processor=x86-64, native/macosx/liblwjgl.jnilib; native/macosx/libjinput-osx.jnilib; native/macosx/openal.dylib; osname=mac os x; processor=x86; processor=ppc
</Bundle-NativeCode>
That is pretty much the whole story of what ext.bundle.opengl.jmonkey is doing.
2) In our
glue.ai application code (in Cogchar and Friendularity projects) there are some
key points where we override and plugin to the JME3 framework, relating to the various
issues with threading and classloading for JME3 classpath assets (e.g. material-shaders,
Ogre models, etc) under OSGi. But actually our code mostly attempts to be agnostic about
whether OSGi container is in effect. Thus we are able to test 3D features using a standalone
main() program (without OSGi), or run a bigger integrated set of features under OSGi. (This
flexibility is valuable in the character robotics context). I also expect it to work under Java 9
modularity whenever that becomes real, with some minor tinkering ;-)
Regarding what those key override/plugin points are. (Blows rusty dust from tome, sneezes loudly)
well, I know we definitely made an OSGi-friendly asset-classpath locator adapter, as
mentioned in the discussions you read. Using that we can plugin different asset bundles.
That code all lives in the Cogchar or Friendularity layers, depending on
the setup you are running. But it is certainly above the layer of the ext.bundle.opengl.jmonkey.
I can (eventually) lookup some relevant java/scala classes if you are interested.
3) Regarding native libraries, the story is similar. There are a few tricks in Cogchar
that make the library load work out nicely in the environments where we actively test.
My memory is foggy but I can gradually dredge up some more info upon request.
(See number 5 below regarding where we are going with this effort).
4) For several years now, our main solution to thread organization is based in akka,
and we write most of that code in scala. It can run with or without OSGi, and we
test both ways. Either way, our application code operates as an akka message
client to the VWorld server code (actors), which wrap around the JME3 features, threads,
native-libs, and other complex runtime issues. In this way app-client threads are decoupled from
messy JME3 operations. Meanwhile In the JME3-touching "server" code we then enforce a simple, app-independent
threading model that avoids collisions of activity inside that server. These are the only threads that
have to actually access assets or talk to JME3 objects, and so the whole world is simpler
These app-thread organization concerns are orthogonal to the OSGi bundling issue, but it seems important to
mention them when describing how an actual
glue.ai application works. You could browse around in the
org.friendularity.lib.viz project, which ultimately makes calls that launch a JME3 canvas and pushes 3D
content into it (with or without OSGi, as I mentioned). Probably the classes in this sub-tree will be most
interesting to you, initially:
http://subversion.assembla.com/svn/friendularity/trunk/maven/org.friendularity.lib.viz/src/main/scala/org/friendularity/vw/impl/5) I guess I am rambling because I don't know if you are more into building some specific OSGi-based game or
application with JME3, or rather you are more interested in achieving the general (but more narrow) technical goal
of OSGi wiring up the JME3 platform itself, for posterity! Is that gradle build for OSGi something you want to
contribute to the JME3 community? If so then maybe you'll want to jump into this thread and introduce yourself.
https://hub.jmonkeyengine.org/t/osgi-bundles-for-jme3/29052
...and feel free to link back to our discussion here in cogchar-users if you like.
Stu