Refactor FileTransferringMessageHandler impls and resepctive Java DSL components

[artembilan]

The FileTransferringMessageHandler hierarchy possible refactoring:

1. Pursue a consistency: an SftpMessageHandler always comes only with the SftpRemoteFileTemplate, so it looks like an FtpMessageHandler has to require only its FtpRemoteFileTemplate. Therefore FtpMessageHandler(RemoteFileTemplate<FTPFile> remoteFileTemplate, FileExistsMode mode) is deprecated and must be replaced with the FtpRemoteFileTemplate-based one.
2. Since SftpMessageHandler cannot be created from the basic RemoteFileTemplate, its SftpMessageHandlerSpec must require a proper SftpRemoteFileTemplate. Therefore those ctors must be deprecated in favor of newly introduced for SftpRemoteFileTemplate
3. Do same for the FtpMessageHandlerSpec
4. I think existing ctors in the FileTransferringMessageHandlerSpec, and therefore - FileTransferringMessageHandler should exist for a while. There might be some use-cases when we can fully rely on the generic RemoteFileTemplate.

[joaquinjsb]

I'm going to give a look to this as well!

[artembilan]

Kinda breaking change in the binary. Moving to the next release.

[deepak5127]

Hi artembilan ,

I am newbie to GitHub contributions. Please let me know if I can take a look into this issue. Thanks

[artembilan]

Hi @deepak5127 ,

Yes, you definitely welcome to take a look into this.
Please, make yourself familiar with our contribution process first of all: https://github.com/spring-projects/spring-integration/blob/master/CONTRIBUTING.adoc

Feel free to ask more question here if any.

Thank you for consider to fix it!

[deepak5127]

Sure, thanks @artembilan

[deepak5127]

@artembilan Started looking into FtpMessageHandlerSpec refacotring. I see RemoteFileTemplate is used in all three specs - inbound, outbound and gateway.

The issue says to refactor only FtpMessageHandlerSpec. So should I keep FtpOutboundGatewaySpec and FtpStreamingInboundChannelAdapterSpec as - is ?

[artembilan]

Let's fix FtpMessageHandler and its FtpMessageHandlerSpec first - Same way we have an SftpMessageHandler! Then we can take a look into gateways and inbound channel adapters.

[deepak5127]

Sure, thanks

[deepak5127]

Sorry one more question, FtpMessageHandlerSpec and SftpMessageHandlerSpec are called from Ftp and Sftp classes. Should i deprecate methods which has (RemoteFileTemplate remoteFileTemplate) and (RemoteFileTemplate remoteFileTemplate, FileExistsMode fileExistsMode) in favor of their respective SftpRemoteFileTemplate and FtpRemoteFileTemplate ?

[artembilan]

@deepak5127 ,

That's correct. I'm fully agree that we need to follow that change anyway.

[deepak5127]

Thanks @artembilan . I have completed the code changes in my local branch.

Couple of questions,

1. In FtpMessageHandlerSpec, for FtpMessageHandlerSpec(FtpRemoteFileTemplate ftpRemoteFileTemplate) method, it is internally calling FtpMessageHandler(SessionFactory sessionFactory) . This again creates new FtpRemoteFileTemplate. I think instead of calling FtpMessageHandler(SessionFactory sessionFactory), we can call FtpMessageHandler(FtpRemoteFileTemplate ftpRemoteFileTemplate, FileExistsMode mode) by sending default FtpRemoteFileTemplate.ExistsMode.NLST ?
2. I dont see Junit written for these outbound adapters in SFTP and FTP tests. Should i write new Test cases in FtpTests and SftpTests ?

[artembilan]

Your observation is correct:

1. We definitely pursue a goal to avoid that FtpRemoteFileTemplate recreation.
2. Yes, more test coverage would be beneficial

Thanks; looking forward for Pull Request from you!

[deepak5127]

@artembilan Created PR