Проблема в UDF: вызов JNI-библиотеки

Андрей Петин

Добрый день.

В маппинге в User-defined function используется набор Java-классов, в одном из которых происходит следующий вызов скомпилированной JNI-библиотеки libjiprivpg.so:

Code:

class IPriv_native
{
   static
   {
      System.loadLibrary("jiprivpg");
   }
...
}

При первом тесте данного маппинга функции из JNI-библиотеки выполнились успешно.
Однако при следующих запусках работа прекращается со следующим сообщением:

Code:

Runtime exception when processing target-field mapping /ns0:Coins/Status; root message: Exception:[java.lang.UnsatisfiedLinkError: Native Library /usr/sap/POD/J00/exe/libjiprivpg.so already loaded in another classloader] in class com.sap.xi.tf._MM_Test_ method TestLib

Т.е. библиотека уже куда-то загружена, и при последующих вызовах loadLibrary таким образом ругается.
Как можно эту проблему обойти? Где нужно выполнять loadLibrary, чтобы при различных прогонах маппинга это не загружалось в разных класслоадерах?

Chaser009

Здравствуйте!

Вопрос, наверное, глупый, но не проще перед загрузкой проверять, загружена или нет? Или в Яве нет таких возможностей?

Chaser009

Посмотрите здесь:
http://scn.sap.com/thread/15622

P.S. Ну и образцово-"костыльный" вариант никто не отменял: обернуть LoadLibrary в try...catch и забить :-)

Андрей Петин

Я так понял, не получится использовать функции библиотеки, если она загружена в другом classloader'е.
Попробовал выполнить код без строчки loadLibrary - ошибка, программа не может выполнить нативные вызовы.
Получается, даже если проверку как-либо всунуть, то библиотека доступна в данной ситуации не будет.

То есть непонятно, как правильно загружать JNI-библиотеку в SAP PI. И вообще практикуется ли это, а то на scn.sap.com нашёл только одно обсуждение подобной ситуации, и то вопрос не решён.

Chaser009

А если попробовать то же самое через java-мэппинг? Может, там по-другому отработает. Плюс, может быть, там что-нибудь типа finalize можно замутить, чтобы выгрузить библиотеку после использования.
Или System.gc() попробовать.

Андрей Петин

Вроде решилась проблема. Помогла нота 542175, хоть она и не про SAP PI, но ситуация похожа.

Jar-файл, который вызывает линуксовую библиотеку (в дальнейшем "обёртка"), выложили в некоторую папку на сервере и вписали его в свойство Java-машины java.class.path (в Netweaver Administrator). Перезапустили Java-часть.
В SAP PI эту обертку не загружали после этого. Пакеты и классы, определенные в этой обертке, нормально импортируются и используются в других jar-файлах, которые уже, в свою очередь, встроены в SAP PI.

Получается доступ к линуксовой библиотеке через некий единый .jar, и конфликтов пока не было.

Chaser009

Вот была, кстати, мысль - подсунуть библиотеки самому java-серверу PI, чтобы он сам их загружал. :-)

Проблема в UDF: вызов JNI-библиотеки

Кто сейчас на конференции