I think that there is benefit in being able to restart webapps individually, even even those within EARs. I also think there should be a distinction between enabling, restarting, and redeploying.
Off the top of my head, disabling should essentially stop the listener from "seeing" the webapp. The webapp may internally still be running (so, for example, if it had any recurring threads they may still run), but the application is efectively dead to the web -- everything gets 404 errors, etc for URLs using the webapp.
We should also be able to stop and restart webapps. A Stopped web app is one that's unloaded from the server, but still "deployed". By unloaded, I mean all of the shutdown lifecycle events have been called, and classes unloaded from memory. If you start a stopped web app, it's no different than if the server is starting up (though server start up may have a different lifecycle event than webapp start up). If someone wanted to "reboot" a webapp (clearing out its singletons, etc.), then stopping and starting the webapp would do the trick.
The final event is deployment. This is when the application is being deployed and configured to run within the container. Standalone webapps should be able to be "redeployed" in place, with all of their server options given to it during original deployment retained (for example, virtual servers, which is not done now).
Webapps bundled within EARs can NOT be redeployed individually of their EAR, but they CAN BE disabled/enabled, and stop/started independent of their EAR.
I think there should be an option that the state of the webapp (disabled, stopped, etc.) should survive survive server restart (so if I have a disabled webapp, and the server restarts, it should still be disabled on startup).
I do not know how this should apply to Web Services deployed on Session Beans. I would think that they should at least be able to be disabled.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=259248