Can I package my own DLLs in WAR?
Yes, but there are many challenges you will face.
-
DLLs are loaded from the file system, not the classpath
This is not a major issue: just store the DLL in your WAR as a resource and copy it to a folder on the file system. The propertyjava.io.tmpdir
must point to a writable directory, or you can useFile.createTempFile()
(just be sure to calldeleteOnExit()
in that file). Then you callSystem.load()
insteadSystem.loadLibary()
. -
You need to manage different DLL copies for different architectures
If you have complete control over your deployment and know that you will only ever deploy to the same machine, then this is not a problem. Otherwise, you will need to write code to figure out which library to load. -
You can only load one library once.
This can hurt you: when you load a shared library, it is linked to the JVM executable. You cannot reload the same library, which means that you cannot redeploy.
When I had to download a shared library to support a web application, I put it in the shared server application directory. It was much easier.
source to share
DLL files are not loaded via the classpath. The Classpath mechanism is only for loading Java resources such as class files and other property files.
One way is to specify the full path to the DLL, or specify it using a system variable java.library.path
. For more details, please see this link .
source to share
No, you cannot. DLLs must be loaded from the file system. You will need (1) a cast iron guarantee that the application server will unpack the WAR files on the file system, and (2) know exactly where the DLL will unpack into the file system so you can name it System.load()
with the correct filename.
source to share
If your dependency hasn't <scope>provided</scope>
, it will be included in the war file regardless of the type (jar, zip, etc., unless it's war).
While this is true, there is a problem that you need to have your own library ( .so
, .dll
) on java.library.path
. EJP questions are valid. However, if you play around with the build plugin and put the dll in /META-INF
your war file directory , you can easily knock the code that extracts that DLL from the classpath /META-INF/my.dll
and places it in the directory on java.library.path
.
It's nowhere near that remotely close to good practice, but I believe you can hack it like that.
source to share
@carlspring: you should be lucky to have write access to any directory in java.library.path. (i.e. program files \ Java, etc.). The best practice might be to unpack the dll to temp directory and add that directory to java.library.path at runtime. This is possible: http://fahdshariff.blogspot.nl/2011/08/changing-java-library-path-at-runtime.html
source to share