Administrator
|
On 12/05/2012 08:45 PM, ryanmohr [via jogamp] wrote:
> Sven Gothel wrote > .. plus my other reply regarding the proprietary status of that method. > I would not dare to include a blob in my project, depending on some weirdo > deployment and maybe even market scheme :) > > Exactly! The only reason we're willing to go to the work of writing a custom > deployment process is to remove or internalize as many variables as possible. > > We need to be able to guarantee that the application we send to our customers > just works (to the point that we'll soon be giving customers the option to > have the JRE embedded, removing one more variable that's given our customers > problems in the past). > > Sven -- I'm giving your suggestions a go right now. Will let you know if I > make any progress. Appreciate the guidance! Pls simply share the onejar demo project (via git/github, as you wish) and we can make an assessment whether it's a bug of GlueGen. However, I am sure we can fix the issue. When you create that project, it might be nice to maybe simply create it as a jogl-demos sub-project (own folder), w/ our jogamp license, so we can share your experience .. ~Sven signature.asc (909 bytes) Download Attachment |
Project is up at https://github.com/saltybits/jogamp-onejar
Feel free to fork it and move it wherever you want. Here's what I get when I run it: java -jar release/release.jar Catched ZipException: error in opening zip file, while TempJarCache.bootstrapNativeLib() of jar:file:/release/release.jar!/lib/gluegen-rt-natives-macosx-universal.jar!/ (file:/release/release.jar!/lib/ + gluegen-rt-natives-macosx-universal.jar) java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1758) at java.lang.Runtime.loadLibrary0(Runtime.java:823) at java.lang.System.loadLibrary(System.java:1045) at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:442) at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:59) at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:90) at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:328) at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:390) at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:251) at com.jogamp.common.os.Platform.access$000(Platform.java:57) at com.jogamp.common.os.Platform$1.run(Platform.java:186) at com.jogamp.common.os.Platform$1.run(Platform.java:183) at java.security.AccessController.doPrivileged(Native Method) at com.jogamp.common.os.Platform.<clinit>(Platform.java:183) at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82) at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:246) at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:196) at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:186) at Driver.main(Driver.java:18) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.simontuffs.onejar.Boot.run(Boot.java:342) at com.simontuffs.onejar.Boot.main(Boot.java:168) |
Sven -- were you able to verify that the jar is unable to load the libraries?
On Wed, Dec 5, 2012 at 10:55 AM, ryanmohr [via jogamp] <[hidden email]> wrote: Project is up at https://github.com/saltybits/jogamp-onejar |
Administrator
|
On 12/06/2012 08:45 PM, ryanmohr [via jogamp] wrote:
> Sven -- were you able to verify that the jar is unable to load the libraries? > Sorry, I had no time for this task yet - but will, Monday the latest. Finally doing video rendering of our Siggraph 2012 happening and then weekend :) Will notify you when I tested your project. ~Sven signature.asc (909 bytes) Download Attachment |
Sounds good Sven. Enjoy your weekend!
On Thu, Dec 6, 2012 at 1:14 PM, Sven Gothel [via jogamp] <[hidden email]> wrote:
|
Administrator
|
Does the single fat JAR approach work fine now with JOGL? It might be interesting even with Java Web Start and trusted certificates because the OCSP server can be slow and using multiple JARs means that you will have multiple OCSP requests.
Julien Gouesse | Personal blog | Website
|
It ended up being a one or two line change to the source to be able to load the libraries as needed on our own so we just went that route. On Thu, Feb 21, 2013 at 2:25 AM, gouessej [via jogamp] <[hidden email]> wrote: Does the single fat JAR approach work fine now with JOGL? It might be interesting even with Java Web Start and trusted certificates because the OCSP server can be slow and using multiple JARs means that you will have multiple OCSP requests. |
Is the change in jogamp or your onejar project? I'm having the same issue, so thanks for already doning the heavy lifting!
Catched FileNotFoundException: \UniversalGcodeSender-all64.jar (The system cannot find the file specified), while TempJarCache.bootstrapNativeLib() of jar:file:/UniversalGcodeSender-all64.jar!/lib/gluegen-rt-natives-windows-amd64.jar!/ (file:/UniversalGcodeSender-all64.jar!/lib/ + gluegen-rt-natives-windows-amd64.jar) Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:442) at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:59) at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:90) at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:328) at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:390) at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:251) at com.jogamp.common.os.Platform.access$000(Platform.java:57) at com.jogamp.common.os.Platform$1.run(Platform.java:186) at com.jogamp.common.os.Platform$1.run(Platform.java:183) at java.security.AccessController.doPrivileged(Native Method) at com.jogamp.common.os.Platform.<clinit>(Platform.java:183) at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82) at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:246) at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:196) at javax.media.opengl.awt.GLCanvas.<init>(GLCanvas.java:186) at com.willwinder.universalgcodesender.visualizer.VisualizerCanvas.<init>(VisualizerCanvas.java:99) ...
|
Administrator
|
Winder, maybe we can find a more viable solution on the long term if you have a similar need. The JARs containing the native libraries might be modified in order to be easier to merge into a single one and GlueGen will have to be modified to load these libraries from such a fat JAR. I succeed in merging JARs with Ant, look at the task "zipgroupfileset".
Julien Gouesse | Personal blog | Website
|
In jogamp. I just added a flag that prevented jogamp from loading the libraries on its own. When our application boots up it just copies everything into place and loads them on our own.
|
In reply to this post by gouessej
I'm using the RXTX serial library which has its own native libraries, their wiki recommended using onejar. It was natural that I ran into this problem later when adding an OpenGL window to the project.
Are you willing to share your bundled fat JAR?
|
Administrator
|
I have failed to make it work reliably but I can write a request for enhancement to prepare some modifications to ease the creation of a fat JAR containing both JOGL & GlueGen classes and native libraries. Currently, you can already use Ant tasks "zip", "fileset", "zipfileset" and "zipgroupfileset" to create a fat JAR but you have to disable the automatic extraction and loading of native libraries in GlueGen and then your JAR will have to extract the native libraries somewhere at runtime because it is impossible to directly load a native library inside a JAR, there is a closed bug report about that. Then, you will have to load them by yourself by using System.load().
Julien Gouesse | Personal blog | Website
|
Yeah, that's exactly the approach we ended up taking.
|
Administrator
|
It would be fine to ease this approach that way:
- the developer shouldn't have to load the libraries by himself, because it can become very tricky in managed environments, especially with Netbeans RCP, when you have one class loader per module and you can't load the same native library twice in a single VM. The order in which libraries are loaded may change a bit in the future... - the libraries should be extracted into the same directory than those we already use in JogAmp. Why reinventing the wheel? The remaining problem is about version conflicts. What happens when an end user runs two applications using different versions of JogAmp APIs?
Julien Gouesse | Personal blog | Website
|
In our case we already have a designated support folder on the user's computer where we store license information and our application log. It was a natural fit to just throw a lib directory in there and keep everything in one place.
All we did was write a simple initializer that identifies the OS, copies the proper libraries into place, and then load them before bootstrapping the rest of our application. If it helps I'd be happy to open source the Platform library I wrote to handle the runtime identification.
Only major downside to this approach is the bloat, since the libraries for all OS's are included in every release. For us that's an easy tradeoff to keep the deployment as simple as possible and be able to rely on a single runnable jar for windows (as exe wrapped through innosetup), mac (as app bundled), and linux.
|
Free forum by Nabble | Edit this page |