We are using YAJSW to wrap our Java application as a Windows Service. While testing workstation images there is a warning from the corporate McAfee Antivirus because on launching the service, the jnidispatch.dll is copied from the jna-4.1.0.jar to a new name in a temporary folder.
Adding the dll signature to the antivirus rules prevents a showstopping error but a severe warning pops up every time.
We tried copying the jnidispath.dll to C:\DLLfolder and adding to wrapper.conf the line:
wrapper.java.additional.4 = -Djna.boot.library.path=C:/DLLfolder/
We then added C:\DLLfolder to the Windows System %PATH% and rebooted Windows.
However when monitoring the Windows Service start, we can still see the DLL being extracted from the Jar instead and the antivirus complains.
The comments in the YAJSW code native.java say:
When JNA classes are loaded, the native shared library (jnidispatch) is
loaded as well. An attempt is made to load it from the any paths defined
in <code>jna.boot.library.path</code> (if defined), then the system library
path using {#link System#loadLibrary}, unless <code>jna.nosys=true</code>.
If not found, the appropriate library will be extracted from the class path
(into a temporary directory if found within a jar file) and loaded from
there, unless <code>jna.noclasspath=true</code>.
What step are we missing?
I confirm we resolved with the following actions:
1) added -Djna.nounpack=true to wrapper.conf
2) deleted the 2 jnidispatch.dll 32-bit and 64-bit DLLs from the JAR
3) Placed the DLLs on the Windows path
Please note to install the Windows Service, the jnidispatch.dll is required.
Big thanks to technomage!
Related
This is probably a trivial question, but I am having trouble installing a Java API called JPIB_Windows into eclipse which should allow me to control external devices connected via GPIB.
This is the contents of the folder that I downloaded.
I created a new project in Eclipse, right clicked the project and went to build path -> configure build path.
I then clicked on add external libraries and added the JPIB.jar file. The file was added, but I am still not able to use the classes in the API.
Is there something else that I need to do to be able to use the API? Is there a better way of importing this API into my project?
You jar file is installed correctly. JPIB (and many other Java libraries) is just wrapper for low-level routines. So it is mandatory to load corresponding native libraries before using Java classes.
In Eclipse go to the Run > Run Configurations... > Arguments tab, select configuration for, perhaps, main method. Then specify in VM arguments field:
-Djava.library.path=C:\path\to\jpib\dll
Then add at the beginning of main() the following line:
System.loadLibrary("jpib_32");
Then run already edited configuration. Everything should be OK. But in case of failure you can examine path to DLL:
System.out.println("Libary path: " + System.getProperty("java.library.path"));
Also working directory can be specified in the same tab, avoiding absolute path, but for the first time absolute path is simple and less error-prone.
Also note that Java may not recognize Windows-specific issues (missing drivers, insufficient user privileges, wrong DLL version) and will report about general error.
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.
My JSP program is set to run on Websphere under HP-UX.
I have some .jar files and a .so file which contains classes that my program needs to run.
By placing my .jar files into \MyProgram\WEB-INF\lib\ folder, I was able to get some to work.
However, I see an UnsatisfiedLinkError which is caused by my lib.so file not being recognised.
One of the ways I found was:
In Administrative Console, go to Environment -> Shared Libraries -> New
Enter the .jar file locations into Classpath, enter the .so file location into Native Library Path
In Administrative Console, go to Applications -> Application Types -> Enterprise Applications
Under MyProgram -> Shared library references -> Shared Library Mapping, assign the library to the program by moving it from Available to Selected.
I have two questions:
Can I just get the .jar files and the .so file to work from my program's \lib\ folder instead?
If I can't, is it possible to list the classpath and native library path from my application folder? Something like uploading my application.war with a websphere variable directory %MYPROGRAM%\WEB-INF\lib\lib.so rather than placing the file in the physical server with an absolute path C:\IBM\WebSphere\AppServer\bin\lib.so?
[EDIT-01] Further details below:
Error received: "Error 500: java.lang.UnsatisfiedLinkError: com.chrysalisits.crypto.LunaAPI.Initialize()V"
I am trying to get Websphere to interface with LunaSA HSM to retrieve public/private keys. They have provided me with: libLunaAPI.sl, libLunaAPI.so, LunaJCASP.jar, LunaJCESP.jar. From IBM's Websphere V8 -> References -> Class Loading Exceptions, it indicates that I need the *.so file for HP-UX so I did that accordingly. The path set are absolute paths which I have specified in the Websphere. This relates to my second question.
The first question is me actually wondering whether I can put these files into myProgram.war and run off from there instead of using WinSCP to access the server and putting files there for absolute paths references. Perhaps specify that the above mentioned files are located in my program, under \WEB-INF\lib\ instead. This is because only this program of mine will be accessing the LunaSA HSM.
** PS. I tried both methods but it still fails. sigh.
For the Shared Library implementation, I believe you specify just the directory in the Native Library Path, not the file name. That is, with your current file location, /opt/apps/WebSphere/AppServer/bin.
On the other hand, I'd expect that directory to already be in WebSphere's WAS_LIBPATH and SHLIB_PATH, so it should be unnecessary to list it at all. (Check $WAS_HOME/bin/setupCmdLine.sh.)
However, I think it would be better to create a subdirectory somewhere for your luna files, and point your Shared Library Native Library Path to that instead.
I have a Java desktop application that I have written.
During the execution I create folders and files at the default path name defined in the system.
Java.io.files clearly states: By default the classes in the java.io package always resolve relative pathnames against the current user directory. This directory is named by the system property user.dir, and is typically the directory in which the Java virtual machine was invoked.
In addition, I am using IzPack to enable installation and shortcuts creation.
When I'm running my application on my XP computer, after the installation I get a desktop shortcut, and the mentioned files and folders creation are at the location that Izpack installed the Jar. which is the expected behavior.
But when I test this out on a Vista machine, the folders and files are created on the desktop! even though the Jar is at the correct location (c:\program files.. etc).
I want those files to be created at the same folder the Jar is in, and most certainly not at the desktop.
Can anyone give me any insights on what is going on here?
It's because in Vista/Seven, writing to the Program Files folder requires administrative interference, so JVM looks for the next writable location as a fallback: the Desktop (or the User Documents directory). You can easily determine the User home directory in a unified manner on all OSs, though, which is way better than just letting the JVM pick a -- hopefully -- reasonable location.
Since this is a known bug for JVM on Windows, if that doesn't help, the fallback is to check the System Environment variable USERPROFILE which should point at the correct user home folder:
String userHome = System.getenv("USERPROFILE");
We currently have an Java application that can be deployed on clients or run as a shortcut from the server. We have intermittently received ClassNotFound exceptions when running the JAR from the server which looks like Windows dropping the network connection with only part of the classes from the JAR loaded (user opens a different screen then the problem is apparent).
I am currently looking at the Web Start technology to allow us to run a single shortcut.
However the application has several folders it requires to be in the same folder the JAR is launched (for configuration, logs, etc.). These folders will require full access for all users to allow them to write log files. There are lots of configuration files under the configuration folder hierarchy.
The application also requires access to environment user settings (such as getting their user folder). It also requires certain command line parameters (including which folder to use for configuration, log file location, java memory usage, etc.)
Edit
The application also contains a reference to 2 signed JARs. These are:
jh.jar
mail.jar
It looks like these are signed by SUN Microsystems. jh is used for help integration in our application whilst mail is used for email integration.
I have now downloaded the latest versions of these files from java2s.com which do not have the signed equivalents.
end edit
The application is developed in Netbeans which compiles a single JAR file and copies the dependant JARs to the dist/lib folder. I enabled the Web Start functionality in Netbeans for the application and it generates the JNLP file.
Bearing everything in mind is Web Start the way to go for an application like this?
Can you include folders in a Web Start deployment? I could not find anything to do this in the XML structure for a JNLP file.
Cheers,
Andez
Yes, you could use WebStart for this.
Permission:
If you need permission to the file system, you have to sign your jars and put the all-permissions tag in your jnlp.
Arguments:
Arguments can be provided by using the arguments elements in application_desc.
Folders:
I'm don't think you can include folders in the WebStart application, but you could put the config files in a jar and read them from there, or extract them on startup.
ClassNotFoundError:
We have intermittently received
ClassNotFound exceptions when running
the JAR from the server which looks
like Windows dropping the network
connection with only part of the
classes from the JAR loaded
Does not sound plausible to me. per default, all jars will be downloaded before the application starts. If you set "download" to "lazy", the jar will be downloaded when first needed, but I would guess it will be downloaded completly then.
You can provide read-only resources for Java WebStart. Getting the log back is harder. I would suggest looking into a centralized logging solution, using one of the standard appenders in the log framework you use.
For a Java Web Start application it is always advised not to create files or folders in the class path. Recommend user's home directory to store your settings or database files.