Clever Geek Handbook

Can I package my own DLLs in WAR?

I am developing a web service that uses native code via JNI. Can I package these dlls in my war?
I'm tired of managing them on my own ...

PS I am using maven.
PPS I am using Tomcat 7.x

+3


source to share


6 answers


Everything is src/main/webapp

packed up to the root of the war, everything is src/main/resources

packed up WEB-INF/classes

. You can pack what you want



+4


source


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 property java.io.tmpdir

    must point to a writable directory, or you can use File.createTempFile()

    (just be sure to call deleteOnExit()

    in that file). Then you call System.load()

    instead System.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.

+4


source


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 .

+3


source


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.

+3


source


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.

+2


source


@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

+1


source






More articles:


All Articles