Details
Description
In version 1.7, when concurrentDOMViews and standardRequestScope are both set to false, a page reload would NOT cause the current request-scoped beans to be disposed and new instances of request-scoped beans to be created. Basically, request-scoped beans would hang around between reloads.
In version 1.8, using the same configuration, request-scoped beans are now disposed and new instances created. The one caveat is that if DisposableBean is implemented, the dispose() method is not called.
We need to decide between:
1) Reverting the behaviour to work like 1.7
2) Leave the existing behaviour but fix the dispose() call
3) Allow both behaviours through some kind of configuration
In version 1.8, using the same configuration, request-scoped beans are now disposed and new instances created. The one caveat is that if DisposableBean is implemented, the dispose() method is not called.
We need to decide between:
1) Reverting the behaviour to work like 1.7
2) Leave the existing behaviour but fix the dispose() call
3) Allow both behaviours through some kind of configuration
I've restored the behavior to what it was in 1.7.2. The noticeable problem was that all request scoped objects were going out of scope on reload, but the dispose() method was not being called on any request scoped beans implementing the DisposableBean interface. This was due to a new ExternalContext always being created on reload. This has been restored in svn version: 18861.
The current behaviour matrix is attached. There seems to be an anomaly with concurrentDOMViews = true and standardRequestScope = false. It might be argued that the request scoped beans should stick around in the case of reload. Digging into this, I found that on reload an $
{app}/block/disposeViews request is sent to the server first, prior to the client re-requesting the page and with concurrentDOMViews set to true, a disposeViews request actually disposes the Views as opposed to only reusing them in the concurrentDOMViews=false case. As part of this disposing the views, the externalContext is disposed. When the View is disposed, all its member variables of course are gone too. This means it would be tricky to keep the externalContext around with the request Map containing the beans. I suggest leaving the behaviour just as it is.