How to use your JME3 Wrapper?

[Thomas Driessen]

Hi :)

I was searching for an OSGi version of JME3. This way I've found your project. 

I just wanted to ask if there is any documentation on how to use your Wrapper of JME3?

My simple approach was to create a new bundle with dependencies to your wrapper (org.cogchar.ext.bundl.opengl.jmonkey) and then create the first tutorial (https://jmonkeyengine.github.io/wiki/jme3/beginner/hello_simpleapplication.html) as a component in OSGi.

@Component(immediate = true)

public class HelloJME3 extends SimpleApplication{

@Activate

public void activate() {

try {

new Thread() {

@Override

public void run() {

HelloJME3 app = new HelloJME3();

app.start();

}

}.start();

} catch (Exception e) {

e.printStackTrace();

}

}

@Override

public void simpleInitApp() {

Box b = new Box(1, 1, 1); // create cube shape

                Geometry geom = new Geometry("Box", b);  // create cube geometry from the shape

                Material mat = new Material(assetManager,

                 "Common/MatDefs/Misc/Unshaded.j3md");  // create a simple material

                mat.setColor("Color", ColorRGBA.Blue);   // set color of material to blue

                geom.setMaterial(mat);                   // set the cube's material

                rootNode.attachChild(geom);              // make the cube appear in the scene

}

}

When I try to resolve this setup, the OSGi resolver complains about com.jme3.asset  is missing. Can you help me please?

Any advice is appreciated :)

Kind regards, 

Thomas

[stub22]

Hi Thomas, thanks for your question.

The com.jme3.asset package is exported by the Cogchar bundle called  ext.bundle.opengl.jmonkey.
If that bundle is wiring up properly, then your issue may be related to the thread-context-classpath
of the thread your code is running on.  Some of what I learned about this topic in 2012 is covered in
this old discussion:

https://hub.jmonkeyengine.org/t/successes-and-challenges-using-jme3-with-osgi-classpaths-and-native-libraries/20052/13

Note that the latest snapshot of JME3 code supplied by this wrapper bundle is from 2014.

At some point we hope to make an updated OSGi wrapper, unless someone else supplies

a more official version.  That topic was last discussed here, as far as I know:

https://hub.jmonkeyengine.org/t/osgi-bundles-for-jme3/29052

Since those discussions, JME has added direct support for maven builds.

https://jmonkeyengine.github.io/wiki/jme3/maven.html

...which will be a helpful starting point for an updated build of the  OSGi wrapper.

If you want to post some info about your runtime environment, (OS, JDK, OSGi Container, build system),
and more details about the error (the exact wiring exception and stack trace), I may have more ideas.
Note that OSGi errors can be tricky, since sometimes the apparent error is really just a symptom of an
earlier failure.

Stu

[Thomas Driessen]

Hi Stu,

thanks for the fast answer.

Meanwhile it worked and I was able to run the sample application. On the second attempt it didn't complain about any assets, but about sun.misc missing. I added sun misc to the -runsystempackages section of bnd and it worked :)

My current setup:

OS: Windows 10 -  64bit

JDK: 1.8.0_112

OSGi Container: Equinox, the current version shipped with Eclipse Oxygen

IDE: Eclipse Oxygen

Buildsystem: Bndtools, which uses Gradle I think.

Currently JME3 is using Gradle as build system, so what would be really nice is a modified buildscript using the bnd gradle plugin to build an OSGi version of JME-3.1 (3.2?).

From your forum posts I can see that you ran into multiple issues with classloading and native code. Did you make changes to the JME3 code published in your bundle to make it work with OSGi or did you resolve these issues otherwise?

Kind regards,

Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "cogchar-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cogchar-users/TuStnBRvoa8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cogchar-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[stub22]

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

in your bundle to make it work with OSGi or did you resolve these issues otherwise?"

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.pom

Our 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