Community
Participate
Working Groups
In Tomcat documentation is stated the following: "Persistence Across Restarts Whenever Apache Tomcat is shut down normally and restarted, or when an application reload is triggered, the standard Manager implementation will attempt to serialize all currently active sessions to a disk file located via the "pathname" attribute (by default "pathname" is SESSIONS.ser). All such saved sessions will then be deserialized and activated (assuming they have not expired in the mean time) when the application reload is completed." In GW the following behaviour is observed: - stop the bundle/stop GW (not uninstall bundle) - SESSIONS.ser is created - right after the step above SESSIONS.ser is deleted, which behaviour is not correct
The behaviour in Tomcat is the following: When one trigger stop of one web application: - StandardContext stop is invoked - If there are active sessions they are persisted - The web application remains attached to the Host - The web application's work directory is not cleared When one trigger undeploy of one web application - StandardContext stop is invoked - StandardContext destroy is invoked - Session information etc. is deleted - The web application is removed from the Host - The web application's work directory is removed In GW implementation when one web application bundle is stopped, its StandardContext is stopped and destroyed. The web application bundle is removed from the Host and its work directory is cleared. This is as it is required by the specification: "128.3.8 Stopping the Web Application Bundle A web application is stopped by stopping the corresponding WAB. In response to a WAB STOPPING event, the Web Extender must undeploy the corresponding Web application from the Servlet Container and clean up any resources. This undeploying must occur synchronously with the WAB’s stopping event. This will involve the following steps: 1. An org/osgi/service/web/UNDEPLOYING event is posted to signal that a Web Application will be removed. See Events on page 426. 2. Unregister the corresponding Servlet Context service 3. The Web Runtime must stop serving content from the Web Application. 4. The Web Runtime must clean up any Web Application specific resources as per servlet 2.5 specification. 5. Emit an org/osgi/service/web/UNDEPLOYED event. See Events on page 426. 6. It is possible that there are one or more colliding WABs because they had the same Context Path as this stopped WAB. If such colliding WABs exists then the Web Extender must attempt to deploy the colliding WAB with the lowest bundle id. Any failure during undeploying should be logged but must not stop the cleaning up of resources and notification of (other) listeners as well as handling any collisions. 128.3.9 Uninstalling the Web Application Bundle A web application can be uninstalled by uninstalling the corresponding WAB. The WAB will be uninstalled from the OSGi framework." So we have to solutions here: 1. To state that we do not support this use case 2. To try to separate the stop and destroy, but keeping in mind that we can have web application bundles with one and the same context paths.
