https://issues.apache.org/bugzilla/show_bug.cgi?id=50836
--- Comment #6 from Mark Thomas <ma...@apache.org> 2011-02-27 05:49:00 EST --- (In reply to comment #5) > 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. If the Javadoc is followed, I don't see how that bug happened. I'd be happy to revist this with a reproducible test case. > I am also concerned with StandardContext#getAvailable() delegating to > LifecycleState#isAvailable(). It is always possible to change the implementation of StandardContext#getAvailable() to check for a more limited set of states. I count 46 references to isAvailable(). I can see at least one place where changing that will break something (ContainerBase.addChildInternal()) and I am concerned that there will be places that are missed if we make this change. > 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. It depends. That exact requirements are defined in the Javadoc and I am in the process of making that Javadoc even more explicit. > 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". I'm happy with that. The listeners should be fired after the state change. Again, I'll clarify this in the Javadoc. > 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". "available" means whatever we define it to mean. I'm happy with the way the current code works but can see lots of places where the Javadoc can be improved. > > 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. That event can still be fired. I have a patch for most of the above, I just need to finish some of the Javadoc improvements. -- 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
