I'll open a JIRA issue for tracking this work. My preference is to go with option two and not change current behavior of the getScopedResponse() method.
Thanks, Carlin On 3/1/07, Carlin Rogers <[EMAIL PROTECTED]> wrote:
Currently, the ScopedServletUtils.getScopedResponse() routine caches the new ScopedResponse result of the first call in the outer request. Then on any subsequent calls it just returns the cached ScopedResponse from the outer request. In some cases there may be multiple calls to getScopedResponse() for a particular scope and a need to pass in a different real Response parameter. However, in these cases the returned ScopedResonse in the subsequent calls will be the cached one which was created in the first call to getScopedResponse() and wraps a different real Response. A modification to ScopedServletUtils could allow one to get a new ScopedResonse instance that wraps the different real Response rather than the cached ScopedResonse. Here are a few potential ways to handle this scenario: 1) getScopedResponse() could check the cached ScopedResponse's realResponse to ensure that it is the same as the realResponse parameter and in cases where it is not, create a new ScopedResponse and update the cache (attribute) in the outer request. 2) Another possibility would be to leave getScopedResponse() as is and add a new method to ScopedServletUtils, such as updateScopedResponse(), that would allow callers to get the new ScopedResponse instance. Any thoughts or preferences? Thanks, Carlin
