+2 Implicit starts may be convienent but they really dont address the notion that children must learn to crawl before they can "run"
-----Original Message----- From: Daniel Rall [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 11:54 AM To: [EMAIL PROTECTED] Subject: Re: Webserver lifecycle problems Jason van Zyl <[EMAIL PROTECTED]> writes: > Right now when you instantiate a WebServer, the listener thread is > started immediately. So the WebServer will accept connections before any > configuration can take place. Where this is problem is when the server > is running in paranoid mode: between the time the server object is > instantiated, which means the listener has started, and the time the > denied clients list is specified any of the clients that should be > denied could potentially connect. > > So what I propose is to provide an additional constructor so that > starting the webserver can be performed explicity: > > (1) > public WebServer(int port, InetAddress add, boolean startExplicitly) > throws IOException > > Which would require the client then to explicitly call start() but would > definitely be more secure in paranoid environments. > > But we might want to stipulate that start() be used explicitly instead > of it being done implicitly when the server object is instantiated. If > we made this change, which I think is the right thing to do, then client > code would break so (1) would be a stopgap measure until we decided what > to do. We can't really deprecate the constructor because we would just > be changing the behavior, so huge warning messages would warranted if we > made this change but people would still probably miss it. > > At the very least I would like to implement (1) which would be backward > compatible but also allow for higher degree of security. We can then > discuss what she would do. I don't think the current behavior is very > good. Good changes, +1. - Dan
