I downloaded and installed a fat-jar eclipse plug-in to be able to package my project containing an external library(JMF). But when I run the application, it says "No device found". Does this mean that jmf.jar wasn't included in the new jar file since it can't detect the webcam? Because when I'm running the application in eclipse, there is no error and it can detect the webcam without any trouble.
How can i solve this problem?
No, "No device found" is a typical JMF response - it can't seem to find a video/audio input or output device. So I think JMF is indeed in your jar and is simply complaining.
Is it possible something is missing from your packed-up classes? Something that is on the classpath in Eclipse but not included in your big jar?
Update
I just remembered where the problem may be: For performance reasons etc, JMF uses native code; installing JMF installs DLL's (Windows) or .so's (Linux/Mac?). I'd guess that JMF is having some trouble finding these components when you make such far-reaching changes to its classpath.
I believe there's also a software emulation driver available. Can you try working with that and seeing if it works OK from the jar?
I had this same problem just now, don't know if you have done this but I solved it by adding the jmf.properties file to the same directory as where your .jar file is located. You can find jmf.properties in the lib directory of the JMF installation directory. Just copy and paste it.
It may be that fatjar uses static code analysis to figure out what class files wind up in the generated JAR, and that the JMF is doing dynamic techniques to load classes from other jars based on a registry of some sort. One way to find out is to run your application with the -verbose:class switch, and then sift through the output to see which class or classes failed to load.
I found a post in the Sun forums where someone else was having trouble with JMF. One responder suggested:
try FMJ (http://www.fmj-sf.net/) or gstreamer-java (http://code.google.com/p/gstreamer-java/).
It's possible (though of course hardly guaranteed) that switching media framework products could be a solution.
Please make sure your jar path, jar path should not be some other path like D: or E: , it should be jmf Installed directory like C:\Program Files (x86)\JMF2.1.1e\lib\jmf.jar. Hope this will help you.
Related
The current Jsoup release 1.7.3 has a known issue that it is using String.isEmpty() which is not supported by Android API Level 8.
I can see crash report of my app so I tried to fix this by change the source code of Jsoup and build my own jsoup.fix.jar. I test this jar with JAVA application and it worked fine on my PC.
I noticed that when I remove the original jsoup-1.7.3.jar from my project, there is errors complaining cannot find jsoup stuff, and the those errors are gone after I add the jsoup.fix.jar which seems to be good. I also check the JAVA build path and the exporting configurations, jsoup.fix.jar are all set as it should.
However, when I tried to run the APP on my Android devices, the APP crashed and saying it cannot find org.jsoup.Jsoup.
I checked the jsoup.fix.jar, opened it with JD-GUI and find the classes are all there, but I used my dex2jar to convert the classes.dex in my /bin directory, I cannot see nay org.jsoup stuff.
Just replace my jar file with the original jar will not have the same issue reproduced.
I also noticed that in my jar, the MANIFEST.MF file only have one line of content, but in the released jsoup-1.7.3.jar, the MANIFEST.MF contains a lot of content.
I am confused now, questions:
Am I doing wrong when build my own jar?
Why the APK still cannot include the jsoup pacakage even I configured it to do so?
Finally I found the reason might be the jar is exported from a JAVA project.
I have tried to create an Android project and copy the source files into it and then export another jar file, and it works!
Could anybody explain why?
I know this has been hashed over a bit on here, but I have an issue that hasn't been answered. I am attempting to install Xuggler plug it into Eclipse. I have no issues with the idea of adding it to my classpath, my issue is with getting my hands on the actual xuggle-xuggler-5.4.jar file. I've installed the one from the website, but there is only a zip folder, and not a jar file. I even tried to pack the file into a jar myself, but Eclipse wouldn't take it. I've looked everywhere in that zip folder and I haven't seen a jar file anywhere. Should just use the zip folder, or did I mess something up? I saw something where a guy had a xuggler file in his Program Files, but I don't have that.
EDIT:
I've been to the googleCode site given on the Xuggler website, and I've clicked on the one that says xuggle-xuggler-5.4.jar. For some reason, though, when I do this, it tries to install as a zip folder, not as a jar. Then it doesn't work in my classpath. When it installs as a zip, like it does in my case, there is no xuggle-xuggler-5.4.jar file on my computer. Instead, the file that was installed is now xuggle-xuggler-5.4.zip.
I don't use Eclipse myself, so I'm not familiar with your particular problem. I do use Xuggler however, and have successfully used the JAR found on their website. So here's just a couple of quick hints. I apologize if I am telling you things you already know.
You can find jar-builds for Xuggler here. Somehow they chose to hide the link on their website somewhat.
There have been previous questions on StackOverflow, such as this one, regarding instructions to add a JAR to an Eclipse project, which will automatically update the classpath and include the JAR during build.
JAR's are in a format that was extended from ZIP, as can be read here. It is unfair to say that JAR files and ZIP files are the same, but you could open a JAR file like you would a ZIP file and read (some) of its content.
Xuggler clearly states this on their website, but I missed it myself, so I thought I'd mention this. The xuggle-xuggler-5.4.jar can be used on any platform. Depending on the codecs you will be using, you might need some additional libraries. To save some disk space you could use xuggle-xuggler-noarch-5.4.jar and an appropriate xuggle-xuggler-arch-xxx.jar as a replacement for xuggle-xuggler-5.4.jar.
I have the following error at runtime, while trying to run Tess4J:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'libtesseract302': Native library (win32-x86-64/libtesseract302.dll) not found in resource path ([myproject/target/classes/, ...some jars...])
My questions are:
1) What exactly it tries to find and where?
2) Why is it apparently searches for myproject/target/classes/ directory? I set it nowhere.
3) Why is it ignores "native directory path" I set for tess4j.jar in user library descripto in Eclipse? My DLLs are there. If it didn't ignore the path, it would find DLLs.
4) Why is it apparently prepending DLL name with win32-x86-64/? I set this nowhere. Is this standard prefix of some API?
5) What is "resource path"? How to set it?
Like the error says, it's looking for win32-x86-64/libtesseract302.dll in java.class.path. Part of your classpath apparently includes myproject/target/classes.
The prefix represents the platform and architecture of the shared library to be loaded, which allows shared libraries for different targets to be included in the same archive. If JNA cannot find the requested library name in the system load path, then it attempts to find it within your resource path (extracting it, if necessary). So if you put the DLL in a jar file, you'll need to give it the win32-x86-64 prefix in order for it to load.
The "resource path" is nominally your class path; basically anywhere reachable by ClassLoader.getResource().
The error stems from your trying to load 32-bit DLLs in 64-bit JVM. The possible solution is switch to 32-bit JVM; alternatively, use 64-bit Tesseract and Leptonica DLLs.
Had the same issue, sorted with the following lines
System.load("/usr/local/lib/liblept.so.5")
System.loadLibrary("tesseract")
For your case, it might be different libraries but in the end is pretty much the same: just load the libraries that you need manually.
Why don't you use JNA API http://www.java2s.com/Code/Jar/j/Downloadjna351jar.htm to load native library? Once you putted into your project classpath, you add this code
NativeLibrary.addSearchPath("libtesseract302", "your native lib path"); make sure you have this libtesseract302.dll file, normally it is located at windows32 folder.
For example, if your libtesseract302.dll file in somewhere c:/abcv/aaa/libtesseract302.dll then you just set the path like this NativeLibrary.addSearchPath("libtesseract302", "c:/abcv/aaa");
I don't know how windows path look like either c:/abcv/aaa or c:\\abcv\\aaa\\
if you want easier way, just put all your necessary dll file into your windows32 folder, JVM will take care of it.
Another issue might be you were not installing the application correctly or the application version is unmatch with your jar version. try to install the latest application and download the latest jar to try again. Hope it helps :)
I had the same problem and found that this "resource path" is not set by "native directory path" .
You can however add new folders to it by using "Add External Class Folder" in the Library tab, even if this folder does not contain any class file but native library files(like DLL on Windows)
A few days ago I ran into the same error message when trying to load a C++ DLL with JNA. It turned out that the cause was a missing DLL that my DLL depended on.
In my case it was the MS Visual Studio 2012 redistributable, which I then downloaded and installed on the machine and the problem was gone. Try using Dependency Walker to find any missing libraries and install them.
I think an easier way to get around this error would be to revert to an earlier version where you were not getting this error. Right click on the project folder and navigate to local history to revert to an earlier version. I verified this workaround on the android studio installed on Mac OS Big sur.
I successfully introduced xuggle in my tomcat environment and it worked perfectly.
Than something happens , and from that moment on, any time my thumbnail generator is called ( is the class that uses xuggle the most) i got the
*java.lang.UnsatisfiedLinkError: Native Library /usr/local/xuggler/lib/libxuggle-xuggler.so.3.4.1012 already loaded in another classloader* exception.
The only way I have to fix it is by restarting tomcat.
Since I can't reproduce the error nor on my laptop, I really appreciate a little help.
This happens probably because you have the Xuggler Jars in a webapp lib directory, and it needs to be at the CATALINA_ROOT directory. See the Xuggler FAQ for details. Stop tomcat, move the Xuggler jar files to the ${CATALINA_HOME}/shared/lib directory and restart tomcat and all should be OK.
If you can't reproduce the same problem on other devices, try to check if your system classpath has entry for this specific jar file because in usual tomcat configuration, system classpath is added along-with lib jar files.
I am building an update system in which I need to be able to replace a referenced jar of a running application jar at runtime. However, I am running into file locking issues on Windows when trying to perform file utility functions on the jar such as 'setLastModified'.
After some googling I found this snippet...
What I found in my research is that
the standard ClassLoader
implementation never closes a jar
file once it has been opened. It also
only loads resources from the jar file
as needed. So at any particular time,
there may be Classes in the jar file
that have not been loaded into memory.
Obviously, if you delete the jar file
out from under the ClassLoader, and it
tries to find a resource in the
missing file, you're going to get an
IOException at the very least.
Does anyone have any references to information on doing this, or working around this issue?
Thanks.
There is a lot of solutions for classes/lib hot-swapping :
Hotswap for ant
JRebel
OSGi
It depends on what you want to do.
The closest thing is OSGi
Please have a look at the 'See also' section of the mentioned artice for concrete products.
I don't know of any good way to deal with this. Creating a custom classloader might be an option, although I don't like that idea..
We worked around it by running an updater from a separate jar before launching the main application. This works well enough, but obviously, you can only update the jar when the application is launched.