[
https://issues.apache.org/jira/browse/FTPSERVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693578#action_12693578
]
Sai Pullabhotla commented on FTPSERVER-253:
-------------------------------------------
Okay, I think I'm ready to work on this and need your inputs in finalizing the
approach. Below is one of the emails I sent a while ago :
----- BEGIN EMAIL -----
Change the signature of the Command.execute to return the FtpReply
(this may not be needed, but I think it makes more sense to do it this
way rather than storing the "lastReply" in the FtpSession. I
definitely prefer this approach.
Create subclasses of FtpReply where Ftplets may want to know
additional information about the result of a command. For example, the
RNTO command returns a RenameFtpReply would contain the fromFile and
toFile information.
I don't think we will have too many subclasses of the DefaultFtpReply,
but I will see what I can do when I dig into the code.
One thing I'm still debating on is - if we really should use FtpReply
objects to provide this additional information or create yet another
abstract class (call it Result) and call back the Ftplet afterCommand
method with the Result instead of the FtpReply. This Result would
contain the FtpReply plus any other information. I prefer this solely
based on the logical structure/naming of the objects. Both approaches
would work fine, except the backward compatibility issue if we decide
to go with the new Result object. To be more specific, the Result
class would look like -
public abstract class Result {
private FtpReply reply;
private boolean success;
private long startTime;
private long endTime;
}
A sub class of Result, RenameResult would look like -
public abstract class RenameResult extends Result {
private FtpFile from;
private FtpFile to;
}
----- END EMAIL -----
I'm leaning towards the second approach of creating a Result object which holds
all the information about the execution result, which includes the FtpReply we
sent.
We cannot use the described soultion #1 (extending DefaultFtpReply) as is
because we have a subclass of DefaultFtpReply which is the LocalizedFtpReply.
So, if we want to go with solution #1 we have to extend the new Reply classes
such as RenameFtpReply from LocalizedFtpReply or get rid of the
LocalizedFtpReply and make the DefaultFtpReply support both English and
Localized messages.
Please let me know what you guys think and we will go from there.
> 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
>
>
> 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.
