How about a scenario where I use two Ftplets one for access control and another for logging? Potentially, I could buy these Ftplets from two different vendors and I do not have access to the source code. So, my logging Ftplet does not work as expected.
> 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). I still am not sure what is the harm in calling the afterCommand method after the command is processed (in this case after the ftplet's beginCommand has finished). Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Thu, Nov 20, 2008 at 2:03 PM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > On Thu, Nov 20, 2008 at 8:26 PM, Sai Pullabhotla > <[EMAIL PROTECTED]> 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 >
