https://issues.apache.org/bugzilla/show_bug.cgi?id=50836
--- Comment #5 from Konstantin Kolinko <knst.koli...@gmail.com> 2011-02-26 19:15:00 EST --- (In reply to comment #4) > > Regarding STARTING: > > > > I think that in STARTING it is too early to call those methods: the > > component > > has not completed its start up. > > It should be OK. Do you have an example of where it isn't? > I do not have one. I was thinking about AccessLog in context of bug 50835 (AccessLog#log() being called on uninitialized valve in unclear circumstances in some broken configuration), but I do not have any custom implementation. I am also concerned with StandardContext#getAvailable() delegating to LifecycleState#isAvailable(). If Child extends AccessLogValve, implementing Child#startInternal() to do not make the component available too soon essentially means that super.startInternal() should be called at the end of child's method, not sooner. Transition to STARTING means that Lifecycle.START_EVENT will be fired after the transition, but we are not waiting for the listeners to complete before declaring the component "available". Transition to STARTED is performed automatically in LifecycleBase#start(). All startup procedures for the component are completed in that state, and I think the STARTED state is better place to mark it as "available". > > Regarding STOPPING_PREP: > > > > My only concern is that the previous state might be FAILED. When > > transitioning > > FAILED -> STOPPING_PREP the availability flag suddenly becomes "true". > > I think we could safely move from FAILED to STOPPING in that case. It means > changing the permitted Lifecycle transitions slightly but from a quick look at > the code it should be ok. I like the idea. It means that we are not firing Lifecycle.BEFORE_STOP_EVENT, but that is not much to lose. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
