NullPointerException в библиотеке скриптов Java

Question

Я делаю первый шаг на пути к Java - пытаюсь создать простую библиотеку сценариев Java в Domino Designer 8.5.2 для выполнения передачи файлов SFTP с использованием JSch 0.1.48. Библиотека будет вызвана из агента LotusScript через LS2J. Вот мой SFTP класс из библиотеки сценариев, основанный на this SO answer:

import com.jcraft.jsch.*; 

public class SFTP { 
    public String GetFile(String host, String user, String pass, 
          String localPath, String remotePath) { 
     JSch jsch = new JSch(); 
     Session session = null; 
     try { 
      session = jsch.getSession(user, host, 22); 
      session.setConfig("StrictHostKeyChecking", "no"); 
      session.setPassword(pass); 
      session.connect(); 
      Channel channel = session.openChannel("sftp"); 
      channel.connect(); 
      ChannelSftp sftpChannel = (ChannelSftp) channel; 
      sftpChannel.get(remotePath, localPath); 
      sftpChannel.exit(); 
      session.disconnect(); 
     } catch (JSchException e) { 
      e.printStackTrace(); 
     } catch (SftpException e) { 
      e.printStackTrace(); 
     } 
     String result = "OK"; 
     return result; 
    } 
} 

Когда я вызываю эту функцию от агента Java, это, кажется, работает без каких-либо проблем. Когда я вызываю его из агента LotusScript через LS2J, он передает файл, но затем он выдает ошибку 318 - Ошибка LS2J: выбрасывает java.lang.NullPointerException. Трассировка стека Java:

java.lang.NullPointerException 
    at lotus.notes.AgentSecurityManager.checkRelatedThreadGroup(Unknown Source) 
    at lotus.notes.AgentSecurityManager.checkAccess(Unknown Source) 
    at java.lang.Thread.checkAccess(Thread.java:378) 
    at java.lang.Thread.interrupt(Thread.java:506) 
    at com.jcraft.jsch.Session.disconnect(Session.java:1630) 
    at SFTP.GetFile(Unknown Source) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) 
    at java.lang.reflect.Method.invoke(Method.java:600) 
    at lotus.domino.JavaConnectInvoker.invoke(Unknown Source) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) 
    at java.lang.reflect.Method.invoke(Method.java:600) 
    at lotus.domino.JavaConnectLoader.invoke(Unknown Source) 

Проблема, похоже, связана с вызовом session.disconnect(). Я нашел других withsimilarissues, вызывающий JSch из других приложений, но если это ошибка JSch, я бы подумал, что агент Java будет генерировать одно и то же исключение. Трассировка стека показывает, что это проблема безопасности Domino, но я не знаю, какую настройку разрешить для этой операции. Агент уже настроен на разрешенные операции, так что это не так. Этот forum post имеет аналогичную трассировку стека и предполагает, что проблема может быть вызвана тем, что Domino владеет правами очистки в своей группе потоков.

Есть ли изменение безопасности, которое мне нужно сделать на стороне Domino? Можно ли удалить session.disconnect() без сиротства соединений на сервере?

Answer 1

Проблема возникла в AgentSecurityManager, о котором вы можете прочитать в this blog entry. Это в основном прокладка, которую Domino AMGR вставляет в JVM для обеспечения соблюдения политик безопасности Domino.

Проверьте, чтобы вы предоставили агент права на использование ограниченных операций. (В другом примере терминологии Lotus «oddball» подписавший должен иметь права в поле «Подписать или запускать неограниченные методы и операции» документа сервера, но агент должен иметь права, предоставленные на вкладке «Безопасность» в поле свойств агента, «Разрешить ограничение операции ")

Если это не так просто, тогда я предлагаю вам попробовать взять банку для com.jcraft.jsch. * из библиотеки сценариев Domino и поместить их в jvm/lib/ext папку на файловой системе сервера. Безопасность для банок, хранящихся в файловой системе, обрабатывается по-разному, и это может обойти проблему.