Calling the verification method in InvocableHandlerMethod#invokeForRequest can be replaced by ControllerInterceptor, because ControllerInterceptor can be used for both verification and other functions, such as log printing. Here is a similar code I implemented earlier

please see my PR https://github.com/spring-projects/spring-framework/pull/31470

demo: my custom function `print log'

@Component
@Slf4j
public class MyControllerInterceptor implements ControllerInterceptor {

    @Override
    public void beforeInvoke(HandlerMethod handlerMethod, Method bridged, Object[] args, HttpServletRequest req) {
        String requestURI = req.getRequestURI();
        log.info("requestURI:{}, method:{}, args:{}", requestURI, bridged, args);
    }

    @Override
    public Object afterInvoke(HandlerMethod handlerMethod, Method bridged, Object[] args, Object returnValue, HttpServletRequest req) {
        String requestURI = req.getRequestURI();
        log.info("requestURI:{}, method:{}, args:{}, returnValue:{}", requestURI, bridged, args, returnValue);
       return returnValue;
    }


}

source InvocableHandlerMethod#invokeForRequest https://github.com/spring-projects/spring-framework/blob/6746bfffa069808a8ac7cb69e333ef82b15d09a5/spring-web/src/main/java/org/springframework/web/method/support/InvocableHandlerMethod.java#L176-L180

https://github.com/spring-projects/spring-framework/blob/6746bfffa069808a8ac7cb69e333ef82b15d09a5/spring-web/src/main/java/org/springframework/web/method/support/InvocableHandlerMethod.java#L183-L186

Comment From: bclozel

I think we need to take a step back here and restart the conversation.

I think this is somehow related to #9447 (and the numerous linked issues) - this is about asking for an interception mechanism at the controller handler level. This also assumes that the method parameters are all parsed, available in memory and that they can be safely consumed by a contract (which is not always the case, like with InputStream variants).

This discussion also started under #28376 around the limitations of HandlerInterceptor and under #30758 for the RequestBodyAdvice and ResponseBodyAdvice contracts.

Comment From: brucelwl

Printing logs is just one of the demos that can be implemented, and there are many other things that can be done. If the parameter is InputStream, users should make special handling for this on their own

Comment From: rstoyanchev

Method validation is an internal feature of the infrastructure for invocation of annotated controller methods, and cannot be easily separated. There is a lot more involved in the decision whether to apply method validation vs validating individual method arguments for backwards compatibility, and that trickles down to the level of individual argument resolvers.

Comment From: brucelwl

@rstoyanchev my original intention was to have a method level interceptor for the Controller

Comment From: rstoyanchev

There are already quite a few interception options between Filter, HandlerInterceptor, RequestBodyAdvice, and ResponseBodyAdvice, @ControllerAdvice, so we're generally not looking to add more. Not without additional justification and concrete use cases in mind, as well as wider applicability and demand.

Comment From: brucelwl

There are already quite a few interception options between Filter, HandlerInterceptor, RequestBodyAdvice, and ResponseBodyAdvice, @ControllerAdvice, so we're generally not looking to add more. Not without additional justification and concrete use cases in mind, as well as wider applicability and demand.

The interceptor I mentioned can be executed closest to the actual call to the Controller, I will provide an example project in the future