Contexts, filters and servlets can all be individually stopped and started in Jetty, with the following results:
A stopped context will not be given any new requests. All components (servlets/filters) of a context will be stopped when stop is called on the context However, there may be an issue with the getContext().getRequestDispatcher() path still being able to inject requests to a stopped context. These should not be handled, but I'll look at dealing with them better. If a request does make it to a stopped servlet, then an Unavailable exception will be thrown. Need to consider if this is correct, maybe their mapping should just dissappear. However, they could still be access by RequestDispatcher that were created before the stop, so the Unavailable exception is correct then. A stop/start of a servlet does the servlet lifecycle destroy/initialize thang. Looking at it, I think I need to tidy up handling of stopped filters. Does JSR77 say anything about managing Filters? They should look pretty much the same as servlets. Note there are no methods to get all the servlets, but it is trivial to add and I will do so shortly. The question is what API should it return for each servlet? Not the servlet itself as calls to the lifecycle methods will go straight to client code and the container will not be able to manage them properly. Jules Gosnell wrote: > Andreas Schaefer wrote: > >> Hi Jules >> >> >>> 1. Are you sure that JSR77 talks at the granularity of Servlets - or is >>> it WebApplications - or both. A Servlet is not the unit of deployment, >>> the WebApplication is. A WebApplication may contain 0-n Servlets. >> >> >> >> JSR-77 have an application (EAR) with one or more modules (WAR,JAR,RAR) >> and each containing eithe EJBs, Servlets or ResourceAdaptors. >> So, yes, JSR-77 needs both the web application and the servlets its >> contains. > > > OK - can do. > >> >> >>> 2. Jetty has a concept of deploy, start, stop and undeploy. Currently >>> webapps are started as soon as they are deployed - so when you say >>> start/stop, do you mean deploy/undeploy or start/stop ? >> >> >> >> JSR-77 is not clear in this point but the lack of the creation of >> services >> I think it means to start/stop but not deploy/undeploy. BTW what does >> start/stop mean (make it available/unavailable to serve) ? What happens >> with the servlets at this time. Can you start/stop servlets ? > > > start/stop means (Greg can give you the exact definition for Jetty) > something like make-available-to-client. If the webapp is stopped, it is > still deployed but the client cannot see it - although it can be > restarted very quickly... > >> >> >>> 3. I am keen for Jetty to support a restart() and a redeploy() - atomic >>> functions which put incoming requests on hold while they do their job - >>> thus ensuring 24*7 service, with no lost requests, even if you upgrade >>> your website at a peak time... I believe JSR77 also has optional? >>> provision for (at least one of) these. I think that it is important that >>> we support it from the start even if it is simply implemented in terms >>> of the others... >> >> >> >> Ahhmm, where did you see that in JSR-77 ? > > > Aha ! - I think I am getting 77 and 88 confused again ! > > Jules > > >> >> Thanx - Andy >> >> >> >> >> ------------------------------------------------------- >> Sponsored by: >> ThinkGeek at http://www.ThinkGeek.com/ >> _______________________________________________ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > -- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
