You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we're wrapping the library in a Spring Boot service like the following.
// error handling redacted
class SFTPService {
public SFTPConnection connect() {
SSHClient ssh = new SSHClient();
ssh.loadKnownHosts();
ssh.connect("localhost");
ssh.authPublickey(System.getProperty("user.name"));
return new SFTPConnection(ssh, ssh.newSFTPClient());
}
So clients would inject the SFTPService and call connect when they need to talk with the SFTP server. Internally SFTPConnection provides some abstraction on top of the library, but mainly it implements a closable interface. So when it is closed we close the current connection and we call disconnect int he sshClient. I'm wondering what are the best practices to handle connections in the context of a bean? Is there any downside on holding a class instance of SSHClient already connected?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently, we're wrapping the library in a Spring Boot service like the following.
So clients would inject the
SFTPService
and callconnect
when they need to talk with the SFTP server. InternallySFTPConnection
provides some abstraction on top of the library, but mainly it implements a closable interface. So when it is closed we close the current connection and we calldisconnect
int he sshClient. I'm wondering what are the best practices to handle connections in the context of a bean? Is there any downside on holding a class instance ofSSHClient
already connected?Beta Was this translation helpful? Give feedback.
All reactions