On Tue, Dec 23, 2008 at 11:22 AM, Jiří Kuhn wrote:
> My approach can be seen in attached file.
I think the patch is fine, could you please attach it to the JIRA
issue to clear the license details?
https://issues.apache.org/jira/browse/FTPSERVER-248
/niklas
When I saw the update I have noticed that there is a code duplicity. And for
someone like me, there is a code inconsistency. The duplicity should be
removed, the inconsistency may be discussed.
The duplicity: Listeners are stopped twice, for first time in
DefaultFtpServer.stop(), for second time i
You've convinced me. I just added the change where we always detroy
the Ftplets on shutdown. Thanks a lot for the motivations!
/niklas
2008/12/22 Sai Pullabhotla :
> I agree with Jiří that if some one chooses to use a custom Ftplet
> container, it is their responsibility to implement the appropri
I agree with Jiří that if some one chooses to use a custom Ftplet
container, it is their responsibility to implement the appropriate
methods (such as init and destroy). All we can do is call the destroy
method when we think the server is going down. I don't see any reason
why we need to keep track
In my opinion, if we call init(), we should call destroy(). It's clear and
logic behaviour. Client may provide an instance of the ftplet container and
the server calls methods defined by an interface, why to make a difference
if the instance is default one or not. The decision is on a client if the
On Fri, Dec 19, 2008 at 8:14 AM, Jiří Kuhn wrote:
> destroy() method on ftplet container is never called. I gues that something
> like
>
>serverContext.getFtpletContainer().destroy();
>
> should be placed somewhere inside DefaultFtpServer.stop() method. Probably
> right just before serverC
Hello,
destroy() method on ftplet container is never called. I gues that something
like
serverContext.getFtpletContainer().destroy();
should be placed somewhere inside DefaultFtpServer.stop() method. Probably
right just before serverContext disposition to be, let's say, consistent
with i