mina-ftpserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sai Pullabhotla" <sai.pullabho...@jmethods.com>
Subject Re: Patch for FTPSERVER-222
Date Thu, 20 Nov 2008 19:26:59 GMT
I attached the patch as a file attachment to the bug. Hope that is
what you wanted me to do. If not let me know.

As far as calling afterCommand everytime, it is logical for an Ftplet
to always expect a notification when a command has finished running
(because that's what the method is intended for). For example, if I
have an Ftplet that traps the beforeCommand method and checks to see
if the user is authorized to run the specific command (for e.g. RETR,
DELE etc). From this method, I send 5xx reply if the user is not
authorized to execute the command. Now, from the same Ftplet, I
implement the afterCommand method and use it to do some kind of
logging which includes the original command as well as the result.
However, the afterCommand is not called if I returned a SKIP from the
beforeCommand which means, my log would miss this command unless I
duplicate the logging code in the beforeCommand also.

Hope this makes sense.


Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861

On Thu, Nov 20, 2008 at 12:49 PM, Niklas Gustavsson
<niklas@protocol7.com> wrote:
> On Thu, Nov 20, 2008 at 6:18 PM, Sai Pullabhotla
> <sai.pullabhotla@jmethods.com> wrote:
>> Attached is the patch for the Jira issue FTPSERVER-222 which calls
>> back the Ftplet.afterCommand method with the actual reply that was
>> sent to the client.
> Please attach this to the issue and make sure you tick the radiobutton
> on approving it for insertion into Apache software.
>> I've tested it reasonably and works as expected. However, there is an
>> issue when the Ftplet.beforeCommand sends a response other than the
>> DEFAULT, then afterCommand is not called any more. I know this was
>> recently changed to behave this way, but I think the afterCommand MUST
>> be called no matter what.
> There was some discussions on this, could you please describe why this
> would be necessary?
> /niklas

View raw message