Hmm. The problem is that the target Url functionality is handled by a separate strategy - there is now no assumption in the AbstractProcessing filter that a SavedRequest exists. It's all handled by the strategy (AuthenticationSuccessHandler). The current ordering of the code means the session state has gone by the time the attempt is made to access the SavedRequest.
The problem is that the amount of functonality in these classes has grown considerable since they were first introduced. Another possibility would be to implement the session fixation logic as another AuthenticationSuccessHandler and call it after the one which performs the navigation. I'm not sure if this will break something else though. Alternatively we could do the same as for LogoutHandler and allow all the "on succes" operations to be configured as a list of AuthenticationSuccessHandlers. Comments are welcome.