The current SavedRequest approach is rather restricted. It would be better if a strategy was introduced which handled the generation of a SavedRequest. With that in mind, SecurityContextHolderAwareRequestFilter should also use a strategy for generating the wrapper, rather than being configured with a wrapper class. This would handle the request matching and generation of the wrapped request, if required.
(default implementation produces a SavedRequest and stores it in the session). Possibly make SavedRequest an interface to allow customization.
HttpServletRequest createRequest(HttpServletRequest request);
(reloads the saved request and returns a wrapper delegating to it). The existing SavedRequestAwareWrapper would be used in a modified form (it currently does the matching itself but that would be done by the factory implementation).
The default SavedRequestHandler could implement both interfaces.
It should also be possible to disable SavedRequest use completely in ExceptionTranslationFilter when the application always uses a default target, for example.