On Fri, Mar 6, 2009 at 02:07, Dhanji R. Prasanna <[email protected]> wrote: > > On Thu, Mar 5, 2009 at 4:19 PM, Endre Stølsvik <[email protected]> wrote: >> >> (This did apparently not reach the list, so I'll try from the webui) >> >> On Mar 3, 8:08 am, "Dhanji R. Prasanna" <[email protected]> wrote: >> > Well, I don't particularly find them useful. Most of the startup or >> > shutdown >> > logic can be encapsulated in the filter's (or servlet's) init() and >> > destroy(). >> > >> > No one has made a compelling argument about why we should support >> > ServletContextListeners. That is not to say there isn't one. Do you have >> > a >> > use case? >> > >> >> Some cents: >> I thought that the init/destroy on servlets (and filters too?) should >> not be used for application startup and shutdown logic, as they per >> specification CAN be invoked several times throughout an application's >> lifecycle (to take down a servlet that hasn't been used for an hour). > > No, are you referring to SingleThreadModel perhaps?
Eh?! No, I am not referring to SingleThreadModel. > Common servlets aren't discarded and restarted--there's too much code out > there which relies on them hanging on to state. As I said, no servlet container I know of actually use this, but the spec (v.2.5) states: SRV.2.3.4: " The servlet container is not required to keep a servlet loaded for any particular period of time. A servlet instance may be kept active in a servlet container for a period of milliseconds, for the lifetime of the servlet container (which could be a number of days, months, or years), or any amount of time in between. When the servlet container determines that a servlet should be removed from service, it calls the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state. For example, the container may do this when it wants to conserve memory resources, or when it is being shut down." To bad if that particular servlet's destroy method takes down your database, right? I always used the most active servlet's init and destroy method for app lifecycle, to kinda mitigate the fear of the container suddenly deciding that some Servlet hadn't been used for a year and thus could just be taken down. Thus, before the introduction of the ServletContextListener, there was really not any proper way to have application lifecycle. This is probably why no servlet container takes down a specific Servlet except when shutting down the entire app (something it obviously does when redeploying an app), as everybody ended up using init and destroy on the servlets to make app lifecycle (employing the load-on-startup attribute to get the app up when the container went up). But it is still not the correct way to do app lifecycle, spec-wise, IIUC. If I made a servlet framework, I'd take that into consideration. SRV.10.1 " The application events facility gives the Web Application Developer greater control over the lifecycle of the ServletContext and HttpSession and ServletRequest, allows for better code factorization, and increases efficiency in managing the resources that the Web application uses. " SRV.10.2: " ... Servlet context listeners are used to manage resources or state held at a JVM level for the application. ..." > >> >> That no servlet container ever have done a destroy() on a servlet >> unless it takes down the entire application doesn't mean that it is a >> safe way to do app lifecycle. > > It is called on webapp redeploy too. So it's fine. Of course it is called on redeploy: "redeploy" means "shutdown" of existing app, followed by "startup" by new app. (And because of the lovely problem with ThreadLocals vs. threadpools, it also means "leaking potential bucketloads of completely unreclaimable memory") > Also curious--why is it > unsafe to take down the entire app as a shutdown hook? JVM shutdown hooks? Well, I don't know - is it unsafe? You'd not get such notifications on redeploy, at least. Endre. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
