Clarify ServletContextListener.contextDestroyed() call requirements on application startup failure
- Dominant language
- Java
- Stars
- 325
- Forks
- 112
- PR merge metrics
- No merged PRs in 30d
Description
When migrating an application from Jboss EAP 6 (Tomcat based) to WildFly, I've encountered a change of behavior with ServletContextListeners that are not cleaned-up properly anymore (contextDestroyed() called) if an exception is thrown during application startup.
Steps to reproduce:
1 - Register two listeners (in web.xml)
2 - First one initializes correctly (contextInitialized())
3 - Second one throws a RuntimeException (contextInitialized())
4 - (On Jboss EAP 6): contextDestroyed() was called on both listeners.
5 - Failed application was undeployed successfully.
Behavior on different servlet implementations:
* Tomcat (up to 9): contextDestroyed() is called on all listeners (including the one that failed to initialize)
* Jboss EAP 6: Same as Tomcat (expected)
* WildFly 8-10: contextDestroyed() not called on any listener.
* Glassfish 4: contextDestroyed() not called on any listener
The 2.5 and 3.0+ servlet-api documents are not clear on the expected behavior.
* 2.5, SRV.9.12 Web Application Deployment
* Explains that contextInitialized() must be called for all instanciated listeners. No clear behavior for contextDestroyed().
* 3.0+, 8.2.3 Assembling the descriptor from web.xml, webfragment.xml
and annotations.
* Clarify the order of initialization and cleanup of listeners (based on order in web.xml).
In my opinion, the behavior I would expect is the following:
* contextDestroyed() SHOULD be called for every listeners for which a successful initialization occured. This way, proper cleanup would be ensured.
* contextDestroyed() SHOULD NOT be called for listeners that failed to initialized. Behaviour would be consistent with the "2.3.2.1 Error Conditions on Initialization" section on servlet initialization/cleanup.
Contributor guide
Assessment
This issue has not been assessed yet.