Re: [FTPSERVER] Ftplets never destroyed

2008-12-23 Thread Niklas Gustavsson
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


Re: [FTPSERVER] Ftplets never destroyed

2008-12-22 Thread Sai Pullabhotla
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 of what Ftplet container is in use and make
decisions based on that.

Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com


On Mon, Dec 22, 2008 at 1:20 AM, Jiří Kuhn jiri.k...@clapix.com wrote:
 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




Re: [FTPSERVER] Ftplets never destroyed

2008-12-22 Thread Niklas Gustavsson
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 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 of what Ftplet container is in use and make
 decisions based on that.

 Regards,
 Sai Pullabhotla
 Phone: (402) 408-5753
 Fax: (402) 408-6861
 www.jMethods.com


 On Mon, Dec 22, 2008 at 1:20 AM, Jiří Kuhn jiri.k...@clapix.com wrote:
 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





Re: [FTPSERVER] Ftplets never destroyed

2008-12-21 Thread Jiří Kuhn
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



Re: [FTPSERVER] Ftplets never destroyed

2008-12-19 Thread Niklas Gustavsson
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