Announcement Announcement Module
No announcement yet.
AbstractFtpSessionFactory fileType javadoc Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • AbstractFtpSessionFactory fileType javadoc

    I'm not sure if anyone else has run into this issue before. I tried searching the forums and google and didn't find anything remotely related to this. We're creating some pdf reports that need to be sent to an ftp server after they are generated.

    We're currently using spring-integration-ftp version 2.0.3 to send the files to the ftp server. The session config for the ftp channel was set up with the fileType set to "3" and we were having some issues where the pdf files weren't readable and acted like they were corrupted.

    It seems like the javadocs AbstractFtpSessionFactory setFileType method are incorrectly documented as:

    * File types defined by {@link} constants.
    * <br>
    * ASCII_FILE_TYPE=0; <br> 
    * EBCDIC_FILE_TYPE=1; <br>
    * @param fileType
    Digging into the source code for Apache common's FTP class the correct constant values are:

    public static final int ASCII_FILE_TYPE = 0;
    public static final int EBCDIC_FILE_TYPE = 1;
    public static final int BINARY_FILE_TYPE = 2;
    public static final int LOCAL_FILE_TYPE = 3;
    By changing the config's fileType to "2", this resolved our issue and the pdf's were transmitted correctly.

    We had some similar code that was transferring files using fileType "3" that worked just fine. However those files were being transmitted from unix to unix and in our case where we had issues we were transferring from unix to windows.

    Unless there's some version mismatch we have going on, can we get the documentation resolved?

    Thanks for your time!

  • #2

    Looking at various mode types i think since you transferring cross systems you need to use either file type 0 or 2
    Type 3 (LOCAL_FILE_TYPE) - Allows two computers with identical setups to send data in a proprietary format without the need to convert it to ASCII


    • #3
      Yes, but our JavaDocs are wrong. @Jonny, would you mind writing up an JIRA issue here...

      Thanks for finding this.


      • #4
        Ok, thanks a bunch for looking into this guys.

        JIRA issue created: