Hi Jerome- I think that your plan sounds reasonable. But I have some general thoughts on the issue:
Have you considered simply removing the Restlet life-cycle methods entirely? Looking at the code, it seems that most included Restlet sub-classes don't have any life-cycle state, and therefor don't override these methods. The main Restlet classes that do are Component and Application. Since I imagine that Application instances rarely contain other Application instances, and that most Applications are contained directly by a Component or a VirtualHost, you could special-case the handling of those classes and remove start/stop from the restlet interface. Another alternative would be to us a separate optional interface, e.g. "StartStopable" or "LifecycleEnabled", and write general restlet code that checks for those interfaces. One of the reasons I suggest this is that I've had experience writing hierarchical component model library APIs (as part of several web/GUI frameworks), and my experience was that the combination of component life-cycles and hierarchical containment (tree-like structures) can cause an explosion of complexity for the framework code, as well as increased complexity for any user's extensions. Additionally, I suspect that many Restlet users will already be using some other form of life-cycle management. Spring framework (as well as other dependency-injection libraries) in part manage the lifecycle of the beans/pojos that the create. And environments like OSGi specify life-cycle at the module or "service" level. A user of restlet may well be faced with many layers in which to potentially write life-cycle code. If you feel that life-cycle methods are necessary, then my thought is that you should provide _very_ explicit documentation on what the contracts are around these life-cycle states, and what expectations the framework will have for any user-supplied Restlet subclasses, especially regarding the _interactions_ between lifecycle state and other behavior. For instance, should a Restlet return an error status if it's "handle" method is called when it is in the "STOPPED" state? Can a STOPPED restlet be re-started by the framework? How does the starting/stopping interact with concurrent access? How does the availability of the Context object change depending on lifecycle? etc. thanks, -Dave Fogel ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1298678
