[
https://issues.apache.org/jira/browse/FTPSERVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sai Pullabhotla updated FTPSERVER-253:
--------------------------------------
Attachment: FTPSERVER-253_Patch.txt
Attached is the first draft of the patch. There is probably more to do
regarding this, but I first wanted you to review it to ensure we are on the
right track.
Below is what I've done so far:
Added two new methods in the FtpReply interface - one that returns the time the
reply was sent and another that tells if the reply is a positive reply
Implemented the above two methods int he DefaultFtpReply.
Added a new method in the FtpRequest interface that returns the time at which
the request was received.
Implemented the above method in the DefaultFtpRequest.
The above 4 items can be used by the Ftplet implementations to determine if the
request was sucessfully processed or not and the total time it took to process
the request.
Added a new method named getPhysicalFile in the FtpFile interface. This method
returns an Object.
The above method is already implemented in the NativeFtpFile.
The above two are needed as most often the Ftplets want to know the physical
location to do any further processing on the file or just to log the physical
file.
Created a new Interface org.apache.ftpserver.ftplet.DataTransferFtpReply
Created a new Interface org.apache.ftpserver.ftplet.RenameFtpReply.
Created org.apache.ftpserver.impl.LocalizedDataTransferFtpReply which exteds
LocalizedFtpReply and implements DataTransferFtpReply
Created org.apache.ftpserver.impl.LocalizedRenameFtpReply which extends
LocalizedFtpReply and implements RenameFtpReply
Updated the APPE, LIST, RETR, STOR, STOU commands to send
LocalizedDataTransferFtpReply. I still have to update the MLSD command I
believe.
Updated the RNTO command to send LocalizedRenameFtpReply.
Created a new utility class named FtpReplyTranslator where all methods that
expand variables and translate messages are kept. These methods are used by the
Localized*FtpReply classes.
Below is what needs to be done if you all like what has been done above:
Create one more extension of FtpReply (may be call it FileActionFtpReply) which
is sent on all commands that act on a file (no data transfer is involved).
These commands include MKD, RMD, DELE, CWD etc. Update these commands to send
the new type of FtpReply.
Other observations:
While working on the above I noticed a couple of things that may need to be
changed/fixed:
1. All data transfer commands (such as LIST, RETR etc) have a block of code
that checks to see if a PASV/PORT command was issued. This code should probably
go into the AbstractCommand instead of having the very same code in 7 different
command implementations. Also, the reply sent when this check fails may need to
be translated.
2. getUniqueFile in STOU command may need to be synchronized. Even if we
synchronize it, there is no gurantee that two different FTP sessions get the
same file as we do not create the file in this method. Perhaps, we should use
File.createTempFile() method to do this.
Hope it all makes sense. Please let me know what you think or need any
clarification.
Regards,
Sai Pullabhotla
> Enhance the Ftplet.afterCommand to provide more information about the result
> of command execution
> -------------------------------------------------------------------------------------------------
>
> Key: FTPSERVER-253
> URL: https://issues.apache.org/jira/browse/FTPSERVER-253
> Project: FtpServer
> Issue Type: New Feature
> Components: Core, Ftplets
> Reporter: Sai Pullabhotla
> Fix For: 1.1
>
> Attachments: FTPSERVER-253_Patch.txt
>
>
> It would be nice to enhance the afterCommand method in the Ftplet to provide
> additional details about the result of command execution. Currently the
> afterCommand method of an Ftplet is called back with the following parameters
> -
> FtpSession, FtpRequest and FtpReply. The FtpReply parameter contains only the
> reply code and the reply string that was sent. The Ftplets may want to know a
> little more information on what exactly happened to the command that was
> executed. For example, the afterCommand for RNTO command might want to know
> the from file, the to file and if the command was successful or not.
> More information on this can be found at
> http://www.mail-archive.com/[email protected]/msg00512.html.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
