2010/2/15 Mark Thomas <ma...@apache.org>: > Currently, Lifecycle is an optional interface for components. I'd like > to make it mandatory for Server, Service and Container.
+1, Let's make it mandatory. I agree with 1.,2.,3. of your reasons. Cannot comment on 4. as I do not know that subject. Is there any outline of those changes? My own observations wrt. to Lifecycle are the following: These are not to object this proposal, but just mere observations. a) Lifecycle has two methods, start() and stop(), and implementors of those have to fire three events each. The JavaDoc for start()/stop() mentions only one event of those three. E.g. for start() those are BEFORE_START_EVENT, START_EVENT, AFTER_START_EVENT, but only START_EVENT is mentioned. b) Server, Service also implement initialize() method. It is a part of their lifecycle, but it is not present in the Lifecycle interface, and there exists Lifecycle.INIT_EVENT. The JavaDoc for Server#initialize() says "This is used to allow connectors to bind to restricted ports under Unix operating environments." so there is a specific reason to have it separated from start(). c) There is also Lifecycle.DESTROY_EVENT, fired by StandardContext.destroy(). Also, not a part of the Lifecycle interface. The JavaDoc comment for StandardContext.destroy() explains why it was needed. d) Once stop() is called, you cannot reuse the component by calling start(). You have to destroy it and call start() on a new instance of it. It is already mentioned in JavaDoc for Lifecycle.stop(), "This method should be the last one called on a given instance of this component.". That is what was once asked and replied on the users@ list. (Somebody using an embedded Tomcat instance was trying to stop() and then start() it). e) Reaction when start() fails (throws a LifecycleException): I think that the component failing to start should be removed from service, (as JavaDoc says "@exception LifecycleException if this component detects a fatal error that prevents this component from being used") but that was not the case in all places - see BZ 48625 and its fix (r752323) Though that might have been an occasional error - I have not searched all places. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org