I'm building a Java app that loads Clojure files. I'm having trouble making a single executable jar. I'm using One-Jar, but I get an exception when I try to run the jar file:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.simontuffs.onejar.Boot.run(Boot.java:340)
at com.simontuffs.onejar.Boot.main(Boot.java:166)
Caused by: java.lang.ExceptionInInitializerError
at com.ziroby.clojure.App.main(App.java:14)
... 6 more
Caused by: java.lang.NullPointerException
at clojure.lang.RT.lastModified(RT.java:374)
at clojure.lang.RT.load(RT.java:408)
at clojure.lang.RT.load(RT.java:398)
at clojure.lang.RT.doInit(RT.java:434)
at clojure.lang.RT.<clinit>(RT.java:316)
... 7 more
When I look at the line that's causing it, it seems to be trying to get jar information for the relative class files:
return ((JarURLConnection) url.openConnection()).getJarFile()
.getEntry(libfile).getTime();
I think this means that it's trying to get jar information for an embedded jar, which doesn't actually exist on the file system. It's looking at that to see if it needs to recompile a file (like common/core.clj).
Am I doing something wrong? Is there some other way to create an executable jar (with dependencies) without confusing Clojure?
I have come to the conclusion that this is a bug in Clojure. I am able to add a single null check (just before the .getTime() call), and it works correctly. I've entered a bug in Clojure's Jira: http://dev.clojure.org/jira/browse/CLJ-971
Related
I'm trying to run the GeoTools ImageLab.java exmaple. It works fine inside Eclipse and I'm using Maven as in the instructions. I'm trying to load a GeoTIFF. But when I use Eclipse to build a runnable jar file and run that from a DOS command line I get:
Jun 11, 2018 6:49:57 PM it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL
WARNING: Failed to load the GDAL native libs. This is not a problem unless you need to use the GDAL plugins: they won't be enabled.
java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.UnsupportedOperationException: Trying to get a reader from an unknown format.
at org.geotools.coverage.grid.io.UnknownFormat.getReader(UnknownFormat.java:53)
at org.geotools.tutorial.raster.ImageLab.displayLayers(ImageLab.java:103)
at org.geotools.tutorial.raster.ImageLab.getLayersAndDisplay(ImageLab.java:87)
at org.geotools.tutorial.raster.ImageLab.main(ImageLab.java:61)
The JNI reference makes me think I need a gdal dll file, but I'm having trouble finding one if that's the case.
All help appreciated! Thanks in advance.
If you are using the gt-imageio-ext-gdal module then you will need to make sure that the JVM can see your gdal libraries and that they are the exact version expected by the module. There are detailed instructions on how to install that on the related GeoServer page.
However, for a simple GeoTiff there is no need for GDAL as this is handled by the gt-geotiff module.
Finally, if you are trying to build a single jar application you should make sure you have read and understood this FAQ entry.
I just tried to run Jetty 9 as non root users, using setuid feature without success for binding low port numbers.
I enabled the module setuid in the start.ini and added -Djava.library.path=/opt/jetty/lib/setuid
But I have the following stack trace when starting Jetty:
2015-06-09 16:27:27.211:WARN:oejx.XmlConfiguration:main: Config error
at | |
java.lang.reflect.InvocationTargetException in
file:/opt/jetty/etc/jetty-setuid.xml
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:321)
at org.eclipse.jetty.start.Main.start(Main.java:817)
at org.eclipse.jetty.start.Main.main(Main.java:112) Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.set(XmlConfiguration.java:479)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:411)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:815)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1125)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1030)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.call(XmlConfiguration.java:721)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:417)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:354)
at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:262)
at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1243)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1174)
... 7 more Caused by: java.lang.UnsatisfiedLinkError: org.eclipse.jetty.setuid.SetUID.getpwnam(Ljava/lang/String;)Lorg/eclipse/jetty/setuid/Passwd;
at org.eclipse.jetty.setuid.SetUID.getpwnam(Native Method)
at org.eclipse.jetty.setuid.SetUIDListener.setUsername(SetUIDListener.java:53)
... 23 more
Those are the only references to this error:
dev.eclipse.org/mhonarc/lists/jetty-users/msg01657.html
groups.google.com/forum/#!topic/dropwizard-user/aap2B_U_QPo
But they are either stopped or do not show the solution.
The source code I found for the setuid package is:
https://github.com/jetty-project/codehaus-jetty-project/blob/master/jetty-setuid/modules/java/src/main/java/org/mortbay/setuid/SetUID.java
Even though I cannot be sure this is the version I am using, given this one is from a org.mortbay package, while the one Jetty 9 uses is an Eclipse one.
I tried setting -Djetty.libsetuid.path in the java args (first try-catch block), either adding the path to the $PATH variable or setting -Djava.library.path (second try-catch block) or copying the so to /lib and, finally, leaving it as it is (third try-catch block). I got the same exception stack in all the cases.
I cannot be sure if Jetty is either not finding the so file or not being able to load it, given that, if I remove all the references to the path (the cases I described latter), I still get the same error message.
I use Java7 to run Jetty.
Edit
I added the following snippet to one of my webapps as as matter of test, given that if the webapp succeed, I would know the problem is not in finding the shared object:
SetUID.setgid(1002);
SetUID.setuid(1002);
Passwd pw = SetUID.getpwuid(1002);
System.setProperty("user.name", pw.getPwName());
System.setProperty("user.home", pw.getPwDir());
I have the same UnsatisfiedLinkError as a result.
Edit2
I tried, instead, the following:
System.load(SetUID.__FILENAME);
SetUID.setgid(1002);
Which got me the following error message:
javax.servlet.ServletException: java.lang.UnsatisfiedLinkError: Native
Library /lib/libsetuid.so already loaded in another classloader
I may conclude, therefore, that the library has been loaded, at least.
Exploring the libsetuid file (nm -D /path/to/the/so), I realized that the so I was using was outdated and was not compatible with Jetty 9, the functions were named as mortbay:
root#root:~/# nm -D libsetuid.so --size-sort | less
0000000000000010 T Java_org_mortbay_setuid_SetUID_setgid
0000000000000010 T Java_org_mortbay_setuid_SetUID_setuid
0000000000000015 T Java_org_mortbay_setuid_SetUID_setumask
0000000000000018 T throwNewJavaSecurityException 0000000000000058 T
throwNewJavaException 000000000000008e T
Java_org_mortbay_setuid_SetUID_setrlimitnofiles 00000000000000a7 T
getJavaMethodId 00000000000000f5 T
Java_org_mortbay_setuid_SetUID_getrlimitnofiles 0000000000000102 T
getJavaFieldInt 0000000000000111 T setJavaFieldInt 0000000000000111 T
setJavaFieldLong 0000000000000121 T setJavaFieldString
00000000000001ba T Java_org_mortbay_setuid_SetUID_getpwuid
00000000000001e5 T Java_org_mortbay_setuid_SetUID_getpwnam
000000000000027e T Java_org_mortbay_setuid_SetUID_getgrgid
000000000000029e T Java_org_mortbay_setuid_SetUID_getgrnam
Now, I am using the shared object that already comes in the jetty download, not the one linked in the wiki.
In addition to that, looking through the code of the setuid module, I decided using the property -Djetty.libsetuid.path in my java args for indicating the absolute path of the lib, e.g., -Djetty.libsetuid.path=/opt/jetty/lib/setuid.so
I'm trying to setup a new project in IntelliJ using LWJGL version 3. I just tried out this example: Whenever I try to run it,
I get a java.lang.ExceptionInInitializerError caused by a java.lang.NullPointerException while loading the library.
My natives are in project_root/lib/lwjgl/native/macosx/x64, so my vm argument is:
-Djava.library.path=lib/lwjgl/native/macosx/x64
I have also added lwjgl to the classpath.
The stack trace is:
Exception in thread "main" java.lang.ExceptionInInitializerError
at test.HelloWorld.execute(HelloWorld.java:18)
at test.HelloWorld.main(HelloWorld.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Caused by: java.lang.NullPointerException
at org.lwjgl.LWJGLUtil.loadLibrarySystem(LWJGLUtil.java:326)
at org.lwjgl.Sys$1.run(Sys.java:36)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:33)
... 7 more
The solution is to specify an absolute path for java.library.path, rather than a relative one.
On the LWJGL forums, there was a user with a similar problem (I found this by searching for the problematic line and doing some hunting on the forum). The relevant part of the conversation is:
lightbringer writes:
I think I figured it out. In LWJGLUtil.java I took out some code and ran it from my main()`. I got an
java.lang.UnsatisfiedLinkError: Expecting an absolute path of the library: lib/native\lwjgl.dll`
inside loadLibrary(). System.load() apparently needs an absolute path but you are passing it a relative path.
I tested with -Djava.library.path=E:\Dropbox\private\projects\solariad\redist\lib\native and this indeed did work as expected.
The root of the issue is LWJGL's use of System.load(), which is not problematic in itself, but it does requires an absolute path name to the libraries it loads (see source as well).
If you take a look at LWJGLUtil.java (although the version at the time of this writing does not correspond exactly to your stack trace) and Sys.doLoadLibrary(), you can see that it attempts to load libraries by going through all the path strings in java.library.path, appending the library name, and trying System.load() on those paths. Since load() requires an absolute path the implication is that java.library.path must contain the absolute path to the LWJGL libraries as well.
It is unfortunate that the root cause of the problem was muddled by the NPE but, you know, it's a hard knock life for us poor programmers!
Hey I am making a game in java using slick and run into all these errors. It works on my friend's computer but not on mine. I've tried on both mac and pc.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1119)
at org.lwjgl.Sys$1.run(Sys.java:73)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
at org.lwjgl.Sys.loadLibrary(Sys.java:95)
at org.lwjgl.Sys.<clinit>(Sys.java:112)
at org.lwjgl.opengl.Display.<clinit>(Display.java:135)
at Game.start(Game.java:37)
at Main.main(Main.java:5)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
What does above exception mean??
I do have it in my class path.
The error message explains it all, you dont have a LWJGL on your classpath. You need to install it so as to get it working on your system.
Also you need to point the jvm to the location where the native files are located using a command line parameter -Djava.library.path="path/to/natives". JarSplice is an alternative to this
You may check this for details
The lwgjl native library cannot be found and loaded. Set the path to the folder where lwjgl.dll (if on Windows, on Mac probably liblwjgl.so) is located, with -D, for instance
java -Djava.library.path=C:\Java\ljwgl\libs com.mypackage.MyProgram
The library files must have a permission to be executed. Some computers may be configured to suppress any execution from USB stick so check.
If still does not work, try to call System.load(String fullFilePath) from your code, pointing to the location where the file clearly exists. If this works at the end, you can use this function to load library without name alterations and path assumptions. If does not, it may be wrong achitecture (64 vs 32 bit, permission problems (not executable) or the library file is just broken.
I'm trying to use one-jar to generate one jar file that contains clojure jar file and java class file: Creating one jar file that for execution from Java/Clojure
Following the instruction, I could generate directories using one-jar-appgen-0.97.jar. As instructed, I replaced the java source, and added the ThingOne-1.0.0-SNAPSHOT-standalone.jar
Running ant, it builds jar file without an error, but I got error messages when I try to execute the jar file.
java -jar build/test-one-jar.jar
test_one_jar main entry point, args=[]
Hello from Java!
Exception in thread "main" java.lang.reflect.InvocationTargetException
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)
Caused by: java.lang.ExceptionInInitializerError
at clojure.lang.Namespace.<init>(Namespace.java:34)
at clojure.lang.Namespace.findOrCreate(Namespace.java:176)
at clojure.lang.Var.internPrivate(Var.java:149)
at ThingOne.core.<clinit>(Unknown Source)
at onejar.main.TestOneJarMain.run(TestOneJarMain.java:27)
at onejar.main.TestOneJarMain.main(TestOneJarMain.java:20)
... 6 more
Caused by: java.lang.NullPointerException
at clojure.lang.RT.lastModified(RT.java:374)
at clojure.lang.RT.load(RT.java:408)
at clojure.lang.RT.load(RT.java:398)
at clojure.lang.RT.doInit(RT.java:434)
at clojure.lang.RT.<clinit>(RT.java:316)
... 12 more
What might be wrong?
Lines 168 and 342 in the Boot.java class of One-Jar indicate a problem with setting properties. This problem is happening when unit tests fail. My guess is it's related to bug 3090800 in the SourceForge One-Jar Bug Tracker.