NullPointerException in Java script library

Question

I am making a first step into Java- trying to create a simple Java script library in Domino Designer 8.5.2 to perform SFTP file transfers using JSch 0.1.48. The library will be called from a LotusScript agent via LS2J. Here is my SFTP class from the script library, based on 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;
    }
}

When I call this function from a Java agent, it appears to work without any issues. When I call it from a LotusScript agent via LS2J, it transfers the file but then it throws error 318 - LS2J Error: Threw java.lang.NullPointerException. The Java stack trace is:

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)

The issue seems to be with the session.disconnect() call. I've found others with similar issues calling JSch from other applications, but if it's a JSch bug I would think the Java agent would throw the same exception. The stack trace makes it look like it's a Domino security issue, but I don't know what adjustment to make to allow this operation. The agent is already set to allow restricted operations, so that's not it. This forum post has a similar stack trace and suggests that the issue may be caused by Domino owning cleanup rights on its thread group.

Is there a security change I need to make on the Domino side? Can I remove the session.disconnect() without orphaning a zillion connections on the server?

Answer 1

The problem occurred in the AgentSecurityManager, which you can read about in this blog entry. It's basically a shim that the Domino AMGR inserts into the JVM to enforce Domino's security policies.

Check to make sure that you have granted the agent rights to use restricted operations. (In another example of Lotus' oddball terminology, the signer must have rights in the "Sign or run unrestricted methods and operations" field of the server document, but agent must have rights granted on security tab of the agent properties box to "Allow restricted operations")

If it's not something simple like that, then I suggest you try taking the jar(s) for com.jcraft.jsch.* out of the Domino script library and putting them in the jvm/lib/ext folder on the server's filesystem. Security for jars stored on the filesystem is handled different, and it might get around the problem.