On 15/02/2010 14:42, Konstantin Kolinko wrote: Thanks for the feedback. All my comments below are preliminary ideas I have had whilst trying to figure out how best to clean this up. Nothing is absolute at this stage but whichever way I thought of things adding Lifecycle to Container always seemed to make things neater hence my proposal in that area first.
Other proposals may follow depending on how the ideas below pan out. If I feel things are getting too invasive, I'll put forward a proposal before I start to commit. > 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? Not yet. Only rough ideas at this stage. In short, I'll need to be able to tell what stage in the Lifecycle the context is in. I am thinking something along the lines of getLifecycleState(). How fine-grained the states will be is TBD. I'll almost certainly use LifecycleSupport to implement this and use the various events to trigger a change in state. > 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. I didn't mention this as I wanted to keep the proposal clean. One of the things I'd like to do as better define what events a method is expected to call, when they should be called and what they signify. eg (more for example than a hard definition at this stage): BEFORE_START_EVENT - fires as early as possible in start() once the component has determined it is going to try to start. If start() is aborted because the component has already started, this event will jot fire. START_EVENT - fired once the component is sufficiently started that dependent components may start(). AFTER_START_EVENT - fired at the very end of the start() method and indicates start() was successful. > 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(). I'm TBD on whether this should be added to the Lifecycle interface. The pragmatic approach is to see how many components use it and how many do not. If the majority implement it then it can be added. > 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. init() and destroy() are mainly used for MBeans. My thinking here is to create an MBeanLifecycle interface that extends MBeanRegistration. This could potentially allow for another fair chunk of clean-up. > 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). That does vary between components. Some will let you start/stop (eg Context) some won't. That might need better documentation. Maybe a restartable marker interface? > 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. Agreed. There was a nastier one where a context would continue if a filter didn't start. If the filter implemented your application's security... Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
