mina-ftpserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Latorre" <dvl...@gmail.com>
Subject Re: Patch for FTPSERVER-222
Date Thu, 20 Nov 2008 23:52:42 GMT
I just checked Spring AOP documentation and this is the kind of things they do:

-beforeAdvice: this is a method executed before a method invocation.
If this 'advice' (interceptor, ftplet method or however you call it)
throws an Exception it will abort All the execution flow (other
interceptors included). So this is basically what we are doing now,
but instead of relying on Exceptions , we are using different return

-afterReturningAdvice: this is executed after the method invocation.
It will be called only if the method returned "successfully" (it
didn't throw an exception). So it works as our afterCommand.

-afterThrowingAdvice: this would be executed only if the invoked
method threw an Exception.

-afterFinallyAdvice: this will be executed no matter what's the return
value of the invoked method.

By the way,  I'm glad that this approach is similar to the one I
myself suggested :P Our difference here would be that we want to
execute afterThrowing and afterFinallyAdvice even if the beforeAdvice
failed. For this to work correctly we have to have commands return a
value or we might need to investigate the ftpreplies sent or maybe
both of them.

* There's also an interceptor called aroundAdvice:  inside its code
our ftplet would be able to execute any code, invoke the command and
continue executing its own code.  This interceptor seems powerful but
I do not think we should try to emulate its behaviour.

So maybe we could implement something like this. Although there're
tricky parts as what are the expected behaviours depending on the type
of result : SKIP or DISCONNECT or when an Exception is thrown from a
ftplet. By the way, I'm not really fond of our closing the connection
when a  documented checked exception is thrown from a ftplet.


2008/11/21 David Latorre <dvlato@gmail.com>
> 2008/11/20 Niklas Gustavsson <niklas@protocol7.com>
>> On Thu, Nov 20, 2008 at 10:02 PM, Sai Pullabhotla
>> <sai.pullabhotla@jmethods.com> wrote:
>> > 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.
>> Buying Ftplets from vendors... that would be the day :-)
>> Anyways, I think you make a good case. David, you were in on the last
>> discussion on this topic. What's your thoughts?
>   I think Sai's suggestion makes sense. Although if you 'bought two Ftplet's from different
vendors' what would the logging ftplet do  when access is denied ? Log that there was an unknown
error ( that access was denied) ? Probably the first ftplet did that already but providing
 more information....
> And then, if  different vendors provided you with  beforeCommand ftplets,  we have the
same case here, the first one in being executed can return a SKIP or DISCONNECT result so
the others won't be executed.
> Anyway, there are several ideas, for example we could add another return code which skips
the command but executes the afterCommands.
>  Anyway if we have the return code now (and we can guess from it that everything worked!
I should check if that's true ...) it is not that important that we can SKIP everything.
> Besides, we also can also implement some kind of "Exception handling ": afterSuccessfulCommand(),
afterCommandError(), afterCommand(). Last once would execute always, the other ones just in
case the command completed correctly or an error occurred. This would allow us for a finer
control of the execution flow.  Maybe we could return a value in commands as well so we can
know if the command finished successfully.
> Our FTPLets remind me very much of AOP, so let me  check how they implement this kind
of behaviour  ( do you know this?   , please step in!).
> What are your thoughts?
>> /niklas

View raw message