[
https://issues.apache.org/jira/browse/FTPSERVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696179#action_12696179
]
David Latorre commented on FTPSERVER-253:
-----------------------------------------
Wow Sai :-)
Are you subscribed to the developers mailing list? So we can move the
discussion there.
I hadn't thought much about these changes myself but your work looks pretty
good. The only thing I don't quite get is why we would use
FTPFile.getPhysicalFile ... Since it returns an Object, the coder developing
the FTPLet should know which 'PhysicalFile' object (s)he is using. This would
mean in most situations that they know which FTPFile implementation they're
using and hence, they could use casting to their appropriate type. And I guess
it's possible to have an implementation of FTPFile that doesn't use a
"PhysicalFile" object ... So what's your use case for this addition? I'm so
tired i can't clearly think...
Another problem we have is that it is becoming quite difficult to develop
pluggable components (be it an UserManager ,a Command or a ftplet) with only
the API documentation. How would a user know which types of FTPReply he should
use if overwriting a command? - I don't have a solution for this at all. It's
just something we could think about.
Agree we should add a bug report for getUniqueFile(), using createTempFile
would be simpler but it is probably better to generate an unique filename and
check for permission before creating the actual file (so all these should be
under a static lock) ; although of course checking only parent directory
permissions we are good to go right now.
> 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.