Proper exception for controller method return types that do not work with MvcUriComponentsBuilder (e.g. final classes) [SPR-16710]

[spring-projects-issues]

Zhang Jie opened SPR-16710 and commented

I create Controller and test case as mvc-reference says:

@Controller
@RequestMapping("/hotels/{hotel}")
public class BookingController {

    @GetMapping("/bookings/{booking}")
    public String getBooking(@PathVariable Long booking) {

    // ...
    }
}

@Test
public void testFromMethodCall() {
	// some necessary code
	UriComponents uriComponents = MvcUriComponentsBuilder
                .fromMethodCall(on(BookingController.class).getBooking(21L)).buildAndExpand(42);
	URI uri = uriComponents.encode().toUri();
	System.out.println(uri);
}

Then I get error as follow:

java.lang.IllegalArgumentException: Cannot subclass final class java.lang.String
at org.springframework.cglib.proxy.Enhancer.generateClass(Enhancer.java:565)
at org.springframework.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:329)
at org.springframework.cglib.proxy.Enhancer.generate(Enhancer.java:492)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91)
at org.springframework.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.springframework.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61)
at org.springframework.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:291)
at org.springframework.cglib.proxy.Enhancer.createHelper(Enhancer.java:480)
at org.springframework.cglib.proxy.Enhancer.createClass(Enhancer.java:337)
at org.springframework.web.servlet.mvc.method.annotation.MvcUriComponentsBuilder.initProxy(MvcUriComponentsBuilder.java:645)
at org.springframework.web.servlet.mvc.method.annotation.MvcUriComponentsBuilder.access$000(MvcUriComponentsBuilder.java:99)
at org.springframework.web.servlet.mvc.method.annotation.MvcUriComponentsBuilder$ControllerMethodInvocationInterceptor.intercept(MvcUriComponentsBuilder.java:769)
at com.example.myproject.controller.BookingController$$EnhancerBySpringCGLIB$$76dd56da.getBooking(<generated>)
at com.example.myproject.GeneralTest.testFromMethodCall(GeneralTest.java:264)

After searching in the source code, I find that, MvcUriComponentsBuilder.on() will create proxy for return value of controll method using ControllerMethodInvocationInterceptor class, just as source says, but my controller method returns String, which's a final class, so cglib can't create subclass for it, then the error occurs.

Does MvcUriComponentsBuilder.on() have any restriction when work with controller method whicht return type is final class?

---

Affects: 4.3.16

Backported to: 4.3.17

[spring-projects-issues]

Juergen Hoeller commented

This is unfortunately a general limitation with MvcUriComponentBuilder's approach: Controller method return types have to be non-final there in order to allow for carrying along the invocation information through a proxy. In your scenario, you could simply declare the return type to Object or CharSequence to make it work.

In any case, this indicates that we should throw a proper exception there pointing out the context of that proxy generation failure.

[spring-projects-issues]

Zhang Jie commented

Thans for your answer, then what about the mvc-reference? It provides an example with final return value, and it dosen't mention the limitation about non-final return value. In fact I was confused with the mvc-reference.Maybe we can also change String in the reference to Object just like the test controller?

[spring-projects-issues]

Juergen Hoeller commented

Good point! I've revised the corresponding section in the MVC reference docs, also adding a note about the technical tradeoff needed for the return signature in case of the mock variant there.

FWIW, the MvcUriComponentsBuilder.fromMethodName variant with the method name as a String works for any signature, even for a String return type.