Closed hdahl closed 9 years ago
Comment #1 originally posted by soi-toolkit on 2014-09-24T15:02:23.000Z:
Initial tests indicates problem with 13 of the 88 one-way testst when upgrading to 3.5.0:
Failed tests: testSftpToJms_ok(org.soitoolkit.tool.generator.onewaysamule350.sftptojms.SftpToJmsIntegrationTest) testFileToVm_ok(org.soitoolkit.tool.generator.onewaysamule350.filetovm.FileToVmIntegrationTest) testSftpToJdbc_ok(org.soitoolkit.tool.generator.onewaysamule350.sftptojdbc.SftpToJdbcIntegrationTest) testFileToSftp_ok(org.soitoolkit.tool.generator.onewaysamule350.filetosftp.FileToSftpIntegrationTest) testSftpToFile_ok(org.soitoolkit.tool.generator.onewaysamule350.sftptofile.SftpToFileIntegrationTest) testFileToFile_ok(org.soitoolkit.tool.generator.onewaysamule350.filetofile.FileToFileIntegrationTest) testFileToFtp_ok(org.soitoolkit.tool.generator.onewaysamule350.filetoftp.FileToFtpIntegrationTest) testFtpToSftp_ok(org.soitoolkit.tool.generator.onewaysamule350.ftptosftp.FtpToSftpIntegrationTest) testSftpToSftp_ok(org.soitoolkit.tool.generator.onewaysamule350.sftptosftp.SftpToSftpIntegrationTest) testSftpToVm_ok(org.soitoolkit.tool.generator.onewaysamule350.sftptovm.SftpToVmIntegrationTest) testFileToJms_ok(org.soitoolkit.tool.generator.onewaysamule350.filetojms.FileToJmsIntegrationTest) testSftpToFtp_ok(org.soitoolkit.tool.generator.onewaysamule350.sftptoftp.SftpToFtpIntegrationTest) testFileToJdbc_ok(org.soitoolkit.tool.generator.onewaysamule350.filetojdbc.FileToJdbcIntegrationTest)
Tests run: 88, Failures: 13, Errors: 0, Skipped: 0
Comment #2 originally posted by soi-toolkit on 2014-09-24T15:35:24.000Z:
Tests for oneway-robust and request-resposne seems to passed without any issues on 3.5.0
Comment #3 originally posted by soi-toolkit on 2014-10-10T21:53:27.000Z:
File inbound-endpoint seems to miss INBOUND scope in the following line: moveToPattern="#[header:originalFilename]"
Removes 5 of the 13 errors, 8 sftp related failures to go...
Comment #4 originally posted by soi-toolkit on 2014-10-11T06:33:52.000Z:
Sftp-output endpoints seems to miss the original-filename when the processing pass the vm-endpoint, e.g. the original filename is not passed along automatically over the vm - protocol (since when, did this work in 3.4/3.3???)
Adding the following
<set-property propertyName="originalFilename"
value="#[header:INBOUND:originalFilename]"
doc:name="Propagate originalFilename to outbound" />
<vm:outbound-endpoint connector-ref="soitoolkit-vm-connector" path="sftpToSftp-service" />
Comment #5 originally posted by soi-toolkit on 2014-10-11T07:13:12.000Z:
Running tests on the sftp-inbound endpoints under Mule 3.5.0 seems to confuse it for where to look for files in some way...
See the following log for an example:
2014-10-11 09:01:15,949 WARN [soitoolkit-sftp-connector.dispatcher.01] org.mule.transport.sftp.SftpClient - listing files for: /~/sftp/sftptofile/inbound/64b903c0-5114-11e4-9864-0a0027000000.dat 2014-10-11 09:01:15,951 ERROR [soitoolkit-sftp-connector.dispatcher.01] org.mule.transport.sftp.SftpMessageDispatcher - Unexpected exception attempting to write file, message was: /sftp/sftptofile/inbound java.io.IOException: /sftp/sftptofile/inbound
It is configured to look for files in the home-folder but looks in the root-folder and naturally then fails on permission problems.
SFTPTOFILE_INBOUND_SFTP_FOLDER=${SOITOOLKIT_SFTP_USERNAME}@localhost:2222/~/sftp/sftptofile/inbound
Manually creating the folders /sftp/sftptofile/inbound and assigning proper permissions to sftp-user resolves the problem but that is of course an unacceptable workaround...
Needs to look into this...
SFTP works for so-toolkit v2 generators and Mule versions >= 3.4.0.
Mule 3.5.0 is supported from early 2.0.0-milestone releases, fully functional (without fixing a generated integration component) from 2.0.0-M5 (where #390 was fixed).
Closing this ticket.
Original issue 378 created by soi-toolkit on 2014-09-22T07:04:27.000Z:
v3.5.0 and v3.5.1 are available in the open source repo: https://repository-master.mulesoft.org/releases/
Steps: