I'm trying to call Sleuth Kit C++ Framework through its JNI wrapper from a JMS MessageListener. But I'm getting this error
java.lang.UnsatisfiedLinkError: /tmp/libtsk_jni.so: libtsk.so.10: cannot open shared object file: No such file or directory
I tried coping the libtsk_jni.so to /tmp but no difference.
But I can do this in a Java console application. What could be the error?
public void onMessage(Message message) {
try {
String imagePath = "uploads/Cfreds001A001.dd";
try{
SleuthkitCase sk = SleuthkitCase.newCase(imagePath + ".db");
} catch (TskCoreException ex) {
}
} catch (JMSException ex) {
Logger.getLogger(WorkerBean.class.getName()).log(Level.SEVERE, null, ex);
} catch (InterruptedException ex) {
Logger.getLogger(WorkerBean.class.getName()).log(Level.SEVERE, null, ex);
}
Attempting to use native methods from code running in a Java EE container is not allowed by the standard and may cause undefined behavior. See the JavaWorld article from August 2000 "Programming restrictions on EJB", still true today as far as I know.
Depending on your Java EE container, you may in fact be able to get this to work. It may help to put the libtsk_jni.so in the system library directory or to edit the server's start script to set the LD_LIBRARY_PATH environment variable.
Related
I am trying to load a DLL file in java program. I do not get an error. However, the DLL library is not loaded. Here is the code snippet:
final class TJLoader {
static void load() {
//System.loadLibrary("#TURBOJPEG_DLL_NAME#");
String path = "C:/Eclipse2/mozpeg-master/bin";
try {
System.out.println("before loading");
//System.loadLibrary("cygjpeg-62");
System.load("C:/image_test/mozjpeg-master/.libs/cygjpeg-62.dll");
System.out.println("2");
} catch (Exception e) {
// TODO Auto-generated catch block
System.out.println("exception="+e);
}catch(Error e){
System.out.println("error="+e.getMessage());
}
}
}
On the console I will get "before loading". However, there is nothing printed after that and the program ends abruptly. Please note the DLL is a 62 bit library and I am using 62 bit JVM
Failure in DLL Loading actually produce java errors. Native errors are produced when you try to invoke a native method. I got java error like "Library not found" when my program failed to load the DLL. You should make sure that your DLL is a 64-bit build and also,try to avoid Cygwin. I used Visual studio to build the DLL and it works fine.Also keep in mind to take the release version instead of the debug version.
Currently, I'm facing an issue where I'm trying to get a WSDL resource from my bundle classpath and then call FileLocator.toFileURL to convert it from a bundle resource to a file resource. At runtime, the method throws a NullPointerException while trying to get an instance of the URLConverter, and I'm pretty baffled as to why this could happen. Below is the code that I'm using.
URL configURL = Preference.class.getResource("/META-INF/wsdl/Preference.wsdl");
if (configURL != null && configURL.getProtocol() != "file") {
System.out.println("URL is not a file. Trying to convert from non-standard to something reference-able.");
URL wsdlURL = null;
try {
wsdlURL = FileLocator.toFileURL(configURL);
} catch (IOException e1) {
System.out.println("IOException caught");
e1.printStackTrace();
} catch (NullPointerException e1) {
System.out.println("NullPointerException caught");
e1.printStackTrace();
} catch (RuntimeException e1) {
System.out.println("RuntimeException caught");
e1.printStackTrace();
} catch (Exception e1) {
System.out.println("generic Exception caught");
e1.printStackTrace();
}
PREFERENCE_WSDL_LOCATION = wsdlURL;
} else {
System.out.println("URL is a file.");
PREFERENCE_WSDL_LOCATION = configURL;
}
When I run the code locally in RAD, it works fine. However, as I think almost everyone who develops OSGi code in Eclipse finds with these kinds of things, it ends up crashing when it's deployed. For me specifically, it is packed into an OSGi Composite Bundle Archive (CBA) and deployed to a WebSphere v8.5.5 app server. Below is the error that I keep running into and its stack trace.
java.lang.NullPointerException
at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:322)
at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.java:205)
at Preference.<clinit>(Preference.java:37)
I did a few sanity checks to make sure I wasn't missing anything obvious. The configURL variable is returning a value (bundleresource://2.fwk685840929/META-INF/wsdl/Preference.wsdl), and all of the dependencies I know of that are necessary for this workflow are added in my classpath (mainly the equinox and eclipse.osgi libraries).
I've google'd all over the place, and found two main resources: the source code for FileLocator and Activator which are both "present at the scene of the crime", and this Eclipse bug report for the exact same line number I'm seeing in my stack trace. However, neither makes sense, because the bug report states that this error would come about from an OSGi plugin not being available - how could this be possible if I'm literally deploying an OSGi bundle to WebSphere's OSGi ecosystem? - and if the line number in grepcode is to be trusted, then the error is apparently the urlTrackers variable which seems like it would be different from a bundle issue and not really something I can control.
I need some help here because I feel like I'm overthinking this a bit. How can I get the FileConverter class to actually work at runtime?
I think the JavaDoc comment is referring to the availability of the org.eclipse.osgi plugin which contains the bundleentry URL converter needed by FileLocator.
I don't think FileLocator is really designed to work outside of the Eclipse RCP environment.
I've been working on in a swing application. I've a JFrame having some buttons and fields.
On some button click event,I'm opening an exe from my current directory. Everything works fine.
try {
Runtime.getRuntime().exec(System.getProperty("user.dir") +
"\\Upgrade\\Upgrade.exe");
} catch (IOException ex) {
ex.printStacktrace();
}
this.dispose(); // disposing my current java file.
But what i need is to exit the java code after opening the exe file.
Anyone help to deal this.?
Can you try making it a process, then waiting for that process to finish before exiting, like so:
class SO {
public static void main(String args[]) {
try {
Process proc = Runtime.getRuntime().exec("your command");
proc.waitFor(); //Wait for it to finish
System.exit(0);
} catch (IOException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
Executing an application from java using Runtime.exec() is a source of well known problems. Like waiting for a Process to finish, but not consuming the data from the stream buffers is a sure way for you application to hang.
I would suggest you use a library like Apache Common Exec to handle this.
I worked on a project a while back where we used Runtime.exec() to launch a process that would eventually extract files over existing files. All worked well except on one machine used for staging - it would just hang. It turned out on that staging machine, someone had set the date/time back so it looked liked the new files being extracted where older than the existing one, causing the external process to generate a warning message for each, overflowing the error buffer - which our application was not consuming!
I'm loading a native library (ffmpeg) using JNA but I need to check if the DLL/SO file exists before actually calling Native.loadLibrary(). FFMPEG may not always be installed in the system (it's a seperate download).
Native.loadLibrary() throws an ERROR which you can not trap with a try {} catch {}.
How do I check if the library (DLL or SO) exists before actually calling loadLibrary()?
Would I have to just parse the PATH environment variable and check myself? I would have to check against Windows and Linux and ensure the correct 32/64bit .dll or .so is installed???
I wish loadLibrary just returned a null pointer or threw an exception, not an error (bad design).
Nevermind, I found the simple soln.
You CAN catch on Error. I thought you couldn't.
I always used try {} catch (Exception e) {} to catch all exceptions but that doesn't catch Errors.
I need to use try {} catch (Error e) {} or catch (UnsatisfiedLinkError ule) {} instead.
Learn something new everyday.
I asked for a solution before, but apparently could not be helped as renjin is rather experimental still...but maybe someone could please translate the error message I get into plain English?
Maybe I can then determine if I can reasonable hope to solve this problem in a reasonable time or if I should rather abandon renjin.
Here is the message:
Exception in thread "AWT-EventQueue-0" org.renjin.eval.EvalException: object 'C_hclust' not found
Here is the code:
private void cluster() {
try {
this.engine.eval("dis<-dist(myMatrix, \"binary\")");
} catch (ScriptException ex) {System.out.println(1);
Logger.getLogger(RWorker.class.getName()).log(Level.SEVERE, null, ex);
}
try {
this.engine.eval("clus<-hclust(dis)");
} catch (ScriptException ex) {System.out.println(3);
Logger.getLogger(RWorker.class.getName()).log(Level.SEVERE, null, ex);
}
try {
this.engine.eval("plot(clus)");
} catch (ScriptException ex) {System.out.println(4);
Logger.getLogger(RWorker.class.getName()).log(Level.SEVERE, null, ex);
}
}
I did not get any of the prints, however.
C_hclust is a function from the stats package written in C but not yet included in Renjin. We are slowly integrating the C/Fortran code from the GNU R stats package as we test and expand our C/Fortran translator.
We're always looking for contributors so this might be a good mini project if you want to get involved - you can take a stab at copying the relevant sources int packages/stats/src/main/c and see if it compiles with out error.
Otherwise completing the functionality of the stats package is a priority and you can look for it in the near future!
I wrote a letter to their mailing list - turns out it is really a bug on their part which will hopefully be fixed soon.