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 destroy() method should be implemented or empty and the destruction of the provided ftplet container is done somewhere else.
The interface defines a contract, if the client breaks it, it will face the consequences itself. At present, if you use everything default, your ftplets are never destroyed(). This is wrong, I think. Jiří Kuhn. 2008/12/19 Niklas Gustavsson <nik...@protocol7.com> > 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 before serverContext disposition to be, let's say, consistent > > with init() method. I really wonder that none has noticed it yet. Or am I > > missing something? > > I'm aware of this, but unsure how we best handle it. If the user has > provided their own FtpletContainer (pretty unlikely but possible), I > think the API client should destroy the container itself. However, in > most cases, clients will simple add Ftplets to the server, in this > case we should destroy on shutdown. So, should we keep track of the > fact that we're using our default provided FtpletContainer and only > destroy if that's true? > > /niklas >
