У меня есть веб-приложение на Java myproject.war
развернут в JBoss. Часть приложения использует JNI для подключения к C ++ DLL, которая вызывает функции из набора сторонних библиотек. Мы переносим это приложение с сервера x32 на сервер x64.
Предыдущая среда сборки
Новая среда сборки
В старой системе пользовательские библиотеки DLL и сторонние библиотеки были просто сброшены в C:\Windows\System32\
и приложение смогло успешно подключиться к ним через JNI. Сторонние библиотеки включают в себя несколько библиотек DLL, некоторые профили ICC и папку ресурсов с подпапками файлов, включая шрифты True-type, конфигурации и другие файлы.
Для миграции был создан модуль JBoss, содержащий код JNI. Код Java / JNI был перемещен в MyModule.jar
, а также MyDriver.dll
был перекомпилирован в x64. Получены x64 версии сторонних библиотек.
я имею
MyDriver.dll
для 64-разрядных с использованием Visual Studio 2010 (10.0.40219.1 SP1Rel)MyDriver.dll
и 64-битные версии сторонних DLL и папки ресурсов в папке модуля ..\main\lib\win-x86_64\
modules
папкаmodule.xml
MyModule.jar
,
MyDriverLoader
какие нагрузки MyDriver.dll
,sun.jdk
что я не уверен на 100%, что нужно для JNI.DLL скомпилирована с
Независимо от того, что я делаю, при запуске приложения JBoss выдает следующую ошибку Java:
java.lang.UnsatisfiedLinkError: D: \ Jboss \ jboss-7.2.0.Final \ modules \ com \ mymodule \ main \ lib \ win-x86_64 \ MyDriver.dll: не удается найти зависимые библиотеки
Что это говорит мне,
Я пробовал следующие решения, но ни одно из них не сработало, и ошибка сохраняется:
{JBOSS_HOME}\modules\com\mymodule\main\lib\win-x86_64
в переменную среды Windows PATH
и подтвердил это echo %PATH%
который включает в себя: D:\Java\jdk1.7.0_45\bin;D:\Jboss\jboss-7.2.0.Final\modules\com\mymodule\main\lib\win-x86_64;
,MSVCP100D.DLL
, MSVCR100D.DLL
а также IESHIMS.DLL
не найдены Я нашел оба MSCV*.DLL
файлы в обоих c:\Windows\System32
а также C:\Windows\SysWOW64
папки, но они имеют разные размеры файлов в каждой. Dependency Walker обнаружил пути к другим файлам system32
, поэтому я не понимаю, почему он не находит MSCV*.DLL
файлы. Чтобы проверить, я бросил их в одну папку ...\lib\win-x86_64
как MyDriver.dll
, но это ничего не изменило.Что я могу сделать, чтобы решить эту проблему?
module.xml
<module xmlns="urn:jboss:module:1.1" name="com.mymodule">
<main-class name="com.mymodule.DriverClassName"/>
<resources>
<resource-root path="MyModule.jar"/>
</resources>
<dependencies>
<module name="sun.jdk"/>
</dependencies>
</module>
MyDriverLoader.java
public class MyDriverLoader {
/**
* Load C++ Library
*/
static {
System.loadLibrary("MyDriver");
}
/**
* Native Method to return the version of the C++ DLL.
*/
public native static String getVersion();
/**
* Main method calls getVersion.
*
* @param args
*/
public static void main(String args[]) {
System.out.println("MyDriverLoader calling MyDriver.dll version " + getVersion());
}
}
jboss-deployment-structure
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="com.mymodule" />
</dependencies>
</deployment>
</jboss-deployment-structure>
структура папок модуля mymodule
:
{JBOSS_HOME} \ Modules \ ком \ MyModule \ главная
- MyModule.jar
- module.xml
- \ Lib \ беспроигрышная x86_64 \
- MyDriver.dll
- ThirdPartyA.dll
- ThirdPartyB.dll
- ThirdPartyC.dll
- ThirdPartyD.dll
- \ Resource \ Data \ Settings \
- foo.optionfile
- bar.optionfile
Я понял это, и вот как.
Сначала я вынул DLL из JBoss и попытался получить к ней доступ непосредственно из вызова нативного метода через JNI на сервере x64 dev / qa. Это не удалось с той же ошибкой. Это означало, что это был не JBoss.
Я удалил ссылки на сторонние библиотеки из DLL и попытался снова получить к ней доступ. Это также не удалось с той же ошибкой. Это означало, что это были не сторонние библиотеки или проблемы с ними.
Я создал простую DLL-библиотеку, которая ничего не делала, кроме выплевывания строки, и пыталась получить к ней доступ так же, как и предыдущие два раза. Это также не удалось. Это означало, что это был не мой код.
Я компилировал DLL в VS 2010 как Debug. Я перекомпилировал DLL как релиз. Это решило проблему.
Я нашел SO ответ, который помог, что я не могу найти снова, иначе я бы связал его.
Как я теперь понимаю, если вы компилируете DLL в Debug, она не должна распространяться. Это было не так с DLL-библиотеками x32, которые я скомпилировал в Debug и которые использовали на моих серверах разработки x32, но, безусловно, был в случае с соответствующей DLL-библиотекой x64. Я скомпилировал как Release и смог использовать DLL во всем приложении.
Я изменил рутину создания будущих развертываемых средств разработки.