You don't need two SecurityEnforcementFilters and you don't need two AuthenticationFilterEntryPoints.
The AuthenticationFilterEntryPoint is used by SecurityEnforcementFilter whenever an AuthenticationException is detected. In other words, when SecurityEnforcementFilter decides the user needs to logon, it launches AuthenticationFilterEntryPoint. You can only have one such filter per webapp. If you really need more customised handling, such as the intended login form is based on the request that was made which failed, you'll need to write your own AuthenticationEntryPoint.
It should also be noted the AuthenticationProcessingFilter.defaultTargetUrl is only called when the login was not as a result of the AuthenticationFilterEntryPoint. If it was the result of the AuthenticationFilterEntryPoint, the SecurityEnforcementFilter will have told the AuthenticationProcessingFilter (via the HttpSession) the URL that should be displayed post-authentication. That URL should be the secured page the user requested but was denied. The defaultTargetUrl only applies if the user logged in of their own accord - not as a result of the application prompting them to. If you want to always ignore the AuthenticationFilterEntryPoint target URL, your best course of action is to write a custom AuthenticationEntryPoint which changes the HttpSession parameter.
Hope this explains a bit more clearly what is going on.
