mina-ftpserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niklas Gustavsson" <nik...@protocol7.com>
Subject Re: Patch for FTPSERVER-222
Date Thu, 20 Nov 2008 20:03:59 GMT
On Thu, Nov 20, 2008 at 8:26 PM, Sai Pullabhotla
<sai.pullabhotla@jmethods.com> wrote:
> 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.

Yes, perfect.

> 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.

Yeah, but the Ftplet has total control over what is happening. So, if
you want to do logging after the command, break that into a method on
it's own and call it from within the code in beforeCommand that sends
the 5xx as well from afterCommand. The reason why I don't think it
makes much sense to call afterCommand is that we (FtpServer) has no
clue what the Ftplet has done, it knows way better than us when the
command (or commands) is complete).

/niklas

Mime
View raw message