[
https://issues.apache.org/jira/browse/CXF-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-189.
-----------------------------
Resolution: Won't Fix
Fix Version/s: Invalid
This improvement request has been open for years and no-one has stepped up to
implement it. As such, it does not seems to be a priority for the existing CXF
community. If, in the future, someone would like to tackle this, feel free to
open is and attach a patch.
Also, this can be achieved today via the Camel transport for CXF and the Camel
FTP component.
> FTP transport
> -------------
>
> Key: CXF-189
> URL: https://issues.apache.org/jira/browse/CXF-189
> Project: CXF
> Issue Type: New Feature
> Components: Transports
> Reporter: Richard Shaw
> Fix For: Invalid
>
>
> I would like to add FTP transport to CXF with the following initial
> requirements.
> 1.0 Client only mode
> 1.1 Input - The client software sends a request and the response is loaded
> from a file on the FTP server. The request is sent to a null stream and the
> filename to load the response from is defined in the WSDL file.
> 1.1.1 There will be one filename per operation defined in the WSDL file if
> the contents of the file do not include the operation name (e.g. CSV binding)
> 1.1.2 There will be one filename per port defined in the WSDL file if the
> contents of the file include the operation (e.g. SOAP binding)
> 1.2 Output - The client sends a one way message and the data is written to a
> file on the FTP serve.r The name of the file is defined in the WSDL file.
> 1.2.1 There will be one filename per operation or port defined in the WSDL
> file. The operation filename will take priority over the port filename.
> 1.2.2 An incrementing filename pattern can be defined in the WSDL file so
> that each message sent is written to a new file
> 2.0 Server only mode
> 2.1 A directory (or tree) is monitored on the FTP server by the transport and
> any new files are read and the contents are passed into the server for
> processing - just as the receipt of a one way message on HTTP is handled.
> This is only for one way messages into the server (see 3.0 for replies)
> 2.1.1 If the contents of the file do not include the operation name a
> filename will be defined for each operation in the WSDL file
> 2.1.2 If the contents of the flie include the operation name then the
> filename will be defined for the port in the WSDL file
> 2.1.3 The poll duration will be defined in the WSDL file
> 2.1.4 Only files that have been created since the last time the direcotry was
> scanned will be processed
> 2.1.5 The order that new files are processed will be defined in the WSDL file.
> 2.1.5.1 Specified order e.g. always load file A before file B
> 2.1.5.2 Use the timestamp on the files and load the oldest first
> 2.1.6 Destructive read can be defined in the WSDL file i.e. the file is
> deleted from the FTP server once consumed.
> 3.0 Client / Server mode
> 3.1 A directory is monitored (as in 2.1) and the new files are passed into
> the servre for processing, the reply to the message is written to a file on
> the FTP server
> 3.1.1 All 2.1.* requirements will apply
> 3.1.2 The filename of the reply is defined in the WSDL file
> 4.0 General
> 4.1 Supports anonymous and authenticated (i.e. log in) access to FTP server
> 4.2 Supports secure FTP - SFTP and FTPS
> 4.3 Would be nice to support files on the local machine too - particularly
> for testing purposes.
> My biggest worry with this is the extent of item 2.1.1. It could get very
> complicated if we want to support all use cases that have been suggested in
> our project.
> I have already implemented 1.1 & 1.2.1 using the java.net URL class. The next
> step is to upgrade to using the apache commons FTPClient class and add server
> support.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
