> > An additional, more subtle, cross-package dependency is probably also > > there -- assumptions about the implemented functionality, or the expected > > order of method calls, that might not always be clearly stated in the > > method JavaDocs. We'll want to review the code for these kinds of cases > > as well. > > This is the one that really bit me in porting ApacheConfig to 4.x. And, as > a result, the 4.x ApacheConfig suffers from the same problem of making > assumptions about the order of method calls. Saying that they might "not > always be clearly stated in the method JavaDocs" is a gross understatement. > Roughly half the time, the "start" event is fired at the beginning (allowing > Listeners to change the config), and half the time it is fired at the end > (allowing Listeners to react to the config). IMHO, the 3.3 event model is > an improvement: where you have an "init" event (fired at the beginning of > the start method), and a "start" event (fired at the end of the start > method).
It's not random, actually. The start event is sent to the listeners at the end of the ContainerBase.start method, which is right after all the children have been started. The only problem is with the server and service, where the start event is sent before (so it's not really useful except to configure things). Adding a before-start event and before-stop event is doable IMO. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
