Hi David, I think it is really useful for Restlet subclasses to have those start/stop methods by default, like Servlets have init/destroy methods. Restlet connectors (Servers mainly) also leverage this.
In addition, this let people potentially do all sort of initialization work, like loading a router configuration from a property file, and removing those would break backward compatibility (we could find workarounds for this, maybe). Regarding complexity, as long as we provide default implementations (that do little actually), this is rather transparent for developers not needing those lifecycle methods. However, for the reasons you gave (IoC, etc.), I'm currently reluctant to go beyond start/stop methods as suggested by this RFE: "Consider detailing the lifecycle states" http://restlet.tigris.org/issues/show_bug.cgi?id=193 Finally, I agree with your advices in the last paragraph and have added them to this new issue report: "Make start/stop usage consistent" http://restlet.tigris.org/issues/show_bug.cgi?id=761 Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : David Fogel [mailto:[email protected]] Envoyé : lundi 9 mars 2009 21:15 À : [email protected] Objet : RE: Re: Why does the Restlet class have lifecycle methods? 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=12986 78 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1317516
