Change in FrameworkServlet makes it impossible to use an alternative WebRequest instance for request processing [SPR-10342]

[spring-projects-issues]

Graeme Rocher opened SPR-10342 and commented

Due to 3643d92

Which was part of the fix for #14659

We are no longer able to use our own WebRequest implementation that extends from ServletRequestAttributes because Spring always overrides it with its own implementation. This has broken various things in Grails' request processing chain.

I have implemented a workaround in Grails that uses delegation instead of subclassing of ServletRequestAttributes, but this may be a breaking change for Grails users, so I'm not sure if it is ideal.

The issue is compounded by the fact there is no way to change this behavior because the method in FrameworkServlet is final

---

Affects: 3.2 GA, 3.2.1

Issue Links:

• Should call getNativeResponse() instead of getNativeRequest() in FrameworkServlet [SPR-15867] #20422 Should call getNativeResponse() instead of getNativeRequest() in FrameworkServlet

0 votes, 6 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

So the fix for #14659 did cause the issue we thought it might. Sam Brannen how about .. revert the change for #14659 and change ServletTestExecutionListener insted to create an anonymous sub-class of ServletWebRequest? In a Spring MVC Test test that will cause the FrameworkServlet to re-create the wrapper with the current request, while in a test using the injected mock request/response, it will simply re-wrap the request.

[spring-projects-issues]

Rossen Stoyanchev commented

Sam, assigning to you since reverting the original change in FrameworkServlet is straight-forward and the should be in ServletTestExecutionListener. Let me know if you have other suggestions though.

[spring-projects-issues]

Juergen Hoeller commented

Graeme, you definitely have a point that the behavior cannot be overridden with that monolithic processRequest method structure, even marked as final. So I'll definitely factor out a few template methods that allow for easy overriding. That should be good enough for Grails since you're subclassing DispatcherServlet anyway - right? And you're explicitly depending on Spring Framework 3.2.2, not requiring backwards compatibility of your newly refined subclass with Spring Framework 3.1.x or 3.2.0/3.2.1?

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Addressed the Grails needs through a buildRequestAttributes template method, extracted from FrameworkServlet.

Also, our RequestBindingInterceptor for Servlet 3.0 async processing now obtains the HttpServletRequest from its locally passed-in request handle and delegates to buildRequestAttributes as well now.

Juergen

[spring-projects-issues]

Graeme Rocher commented

Thanks Juergen - And yes we subclass DispatcherServlet and depend on an explicit version of Spring, so this change should be fine for us