Issue Details (XML | Word | Printable)

Key: SPR-4516
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Juergen Hoeller
Reporter: Chris Lee
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Spring Framework

@RequestMapping invokes incorrent handler method

Created: 28/Feb/08 12:19 PM   Updated: 28/Feb/08 03:16 PM
Component/s: SpringWEB
Affects Version/s: 2.5.2
Fix Version/s: 2.5.2

Time Tracking:
Not Specified

Environment: Nightly Build of 2.5.2 - 2/16


 Description  « Hide
The below test case (created after experiencing the problem in a full blown app) contains two methods - one annotated @RequestMapping, the second @RequestMapping( method=RequestMethod.POST) - this is causing requests for the first method to be incorrectly dispatched to the second method.

import java.io.PrintWriter;

import javax.servlet.http.HttpServletResponse;

import junit.framework.TestCase;

import org.springframework.mock.web.MockHttpServletRequest;
import org.springframework.mock.web.MockHttpServletResponse;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter;

public class SpringAnnotationMethodHandlerAdapterParameterTest extends TestCase
{

    public void testSingleMethod() throws Exception
    {
        executeTest( "/foo/handleBill?", new MultiMethodController() );
        executeTest( "/foo/generateFromReconciliation", new MultiMethodController() );
    }

    private void executeTest( String url, Object handler ) throws Exception
    {
        AnnotationMethodHandlerAdapter amha = new AnnotationMethodHandlerAdapter();

        MockHttpServletRequest request = new MockHttpServletRequest( "POST", url );
        request.addParameter( "data", "foo" );
        HttpServletResponse response = new MockHttpServletResponse();

        amha.handle( request, response, handler );
    }

    @Controller
    @RequestMapping( value = { "/foo/*", "/bar/*" }, method = RequestMethod.POST )
    public static class MultiMethodController
    {
        @RequestMapping
        public void handleBill( @RequestParam( "data" )
        String data, PrintWriter out ) throws Exception
        {
            System.out.println( "handleBill" );
        }

        @RequestMapping( method = RequestMethod.POST )
        public void generateFromReconciliation( @RequestParam( "data" )
        String data ) throws Exception
        {
            System.out.println( "generateFromReconciliation" );
        }

    }
}


 All   Comments   Work Log   Change History   FishEye   Builds      Sort Order: Ascending order - Click to sort in descending order
Chris Lee added a comment - 28/Feb/08 12:20 PM
Removing the POST on the second @RequestMapping reverts the behaviour to what is expected

Juergen Hoeller added a comment - 28/Feb/08 03:03 PM
This is arguably a bit of contrived example - with the HTTP method limitation specified at the type level as well for *one* of the two handler methods (i.e. not for both handler methods)

 Since handler method names are only taken into account as a fallback (i.e. they do not form a primary mapping themselves but are rather only used for resolving ambiguities), the mapping is currently processed as "most specific match" - always the second method here, even if it repeats the type-level restriction.

I'll revise that to detect restrictions that do not add expressive value, i.e. only repeat what has been specified at the type level already. I would generally not add such redundant restrictions in the first place, though - or if you repeat those at the method level, then do it for all affected methods,

Juergen

Chris Lee added a comment - 28/Feb/08 03:06 PM
Thanks Juergen. The redundant restriction was a holdover from before it could be defaulted @ the class level.

Juergen Hoeller added a comment - 28/Feb/08 03:16 PM
OK, I've revised the resolution algorithm to disregard redundant mapping information for ambiguity resolution now.

Juergen