RE: Re: Why does the Restlet class have lifecycle methods?
Hi Dave, In general, you should pass the parent context to the constructor of your Restlet or Resource subclass. Otherwise, in some cases, the setContext() is used for late setting of this context. I agree that it would be useful to propagate this call like for lifecycle method. I've taken note of this and will do it ASAP. 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:carrotsa...@gmail.com] Envoyé : jeudi 19 mars 2009 05:08 À : discuss@restlet.tigris.org Objet : RE: Re: Why does the Restlet class have lifecycle methods? Hi Jerome- In addition to propagating start/stop life-cycle methods to any contained or child restlets, should restlets also, by contract, propagate any new Context they receive via setContext()? I'm not sure what the solution is, but I've been finding that I don't always have access to a Context at Restlet creation time, and then it becomes an issue when restlets contained within other restlets never get a Context set on them. Recommended practice? -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13530 81 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1416229
RE: Re: Why does the Restlet class have lifecycle methods?
Hi Jerome- In addition to propagating start/stop life-cycle methods to any contained or child restlets, should restlets also, by contract, propagate any new Context they receive via setContext()? I'm not sure what the solution is, but I've been finding that I don't always have access to a Context at Restlet creation time, and then it becomes an issue when restlets contained within other restlets never get a Context set on them. Recommended practice? -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1353081
RE: Re: Why does the Restlet class have lifecycle methods?
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:carrotsa...@gmail.com] Envoyé : lundi 9 mars 2009 21:15 À : discuss@restlet.tigris.org 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=4447dsMessageId=12986 78 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1317516
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=4447dsMessageId=1298678
RE: Re: Why does the Restlet class have lifecycle methods?
Hi David, I think you put the finger on a serious issue here... We need to make this behavior more predictable and consistent. I suggest that we systematically propagate the start/stop actions to attached Restlets: - 'next' Restlet for a Filter - 'root' Restlet for an Application - 'routes' Filters for a Router - etc. This will also remove the current lazy start behavior, but this should be mostly backward compatible. Any opinion before I change the code in SVN trunk? 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:carrotsa...@gmail.com] Envoyé : jeudi 26 février 2009 20:45 À : discuss@restlet.tigris.org Objet : RE: Re: Why does the Restlet class have lifecycle methods? Hi Stephen- Well, I'm not sure I understand what it means to be correctly integrated- we're creating Restlet subclasses and adding them to Routers, VirtualHosts, Filters, etc. Is there something else we need to do to register them somehow? Looking at the source code in Router, Filter, Application, VirtualHosts (this is in 1.2M1), I don't find any code which propagates calls to stop() to the children of the restlets. Could this be because there isn't a strict parent-child relationship in restlet? I suppose a single restlet instance could be attached to multiple parent Routers, which I suppose might make it unclear specifically whose responsibility it is to call stop() on the Restlet. Still, it seems to me that if the Restlet API is going to have these lifecycle methods on what is effectively the base class for all request-routing entities, that there should be some specific contract as to when these methods get called. Otherwise maybe they belong in a separate interface? As an aside, I'm also not a big fan of having the Restlet.handle() method lazily call start() on itself. This provides a very unreliable lifecycle for a component. I think it might make more sense to have the parent of the restlet call start() on it, either when it itself is started, or when the child is attached/added/set, etc. But this too has its own drawbacks. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12345 18 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278610
RE: Re: Why does the Restlet class have lifecycle methods?
Hi Stephen- Well, I'm not sure I understand what it means to be correctly integrated- we're creating Restlet subclasses and adding them to Routers, VirtualHosts, Filters, etc. Is there something else we need to do to register them somehow? Looking at the source code in Router, Filter, Application, VirtualHosts (this is in 1.2M1), I don't find any code which propagates calls to stop() to the children of the restlets. Could this be because there isn't a strict parent-child relationship in restlet? I suppose a single restlet instance could be attached to multiple parent Routers, which I suppose might make it unclear specifically whose responsibility it is to call stop() on the Restlet. Still, it seems to me that if the Restlet API is going to have these lifecycle methods on what is effectively the base class for all request-routing entities, that there should be some specific contract as to when these methods get called. Otherwise maybe they belong in a separate interface? As an aside, I'm also not a big fan of having the Restlet.handle() method lazily call start() on itself. This provides a very unreliable lifecycle for a component. I think it might make more sense to have the parent of the restlet call start() on it, either when it itself is started, or when the child is attached/added/set, etc. But this too has its own drawbacks. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1234518
