On Tue, Dec 23, 2008 at 11:22 AM, Jiří Kuhn jiri.k...@clapix.com 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
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
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 sai.pullabho...@jmethods.com:
I agree with Jiří that if some one chooses to use a custom Ftplet
container, it is their
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
On Fri, Dec 19, 2008 at 8:14 AM, Jiří Kuhn jiri.k...@clapix.com 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
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
