Currently WebFluxAutoConfiguration enables the RouterFunction programming model, but doesn't give any option to skip the @RequestMapping approach. With the runtime performance gains that can be made using functional style configuration, it seems like Spring Boot should be able to support WebFlux.fn (and MVC.fn) without also enabling annotation-based controller programming models. There won't be a classpath signal that the user wants only fn endpoints, so it might have to be an Environment property that switches it on (and switches off WebFluxAutoConfiguration probably). Maybe it's a change that needs to be driven through from Spring Framework?
Comment From: sdeleuze
I would be interested by this for GraalVM native support. If changes are needed on Framework side, I would be interested to tackle it, I guess @poutsma would be as well.
Comment From: sdeleuze
Like for spring.spel.ignore or spring.xml.ignore, the spirit of such flag would potentially be to be automatically set later by analyzing the application at build time to check if it has any usage of @RequestMapping. For now we can live by setting it manually.
Comment From: wilkinsona
Thanks for the suggestion. Based on my understanding of how things work at the moment for WebFlux.fn and MVC.fn, I think this will need some changes in Framework.
Boot's WebMvcAutoConfiguration and WebFluxAutoConfiguration don't do anything in particular to enable the fn web support, they inherit it from WebMvcConfigurationSupport and WebFluxConfigurationSupport respectively. Both of those support classes also define beans related to their annotation-based programming models such as their respective RequestMappingHandlerAdapters.
It might be possible to get close to some fn-only auto-configuration by overriding lots of methods and not using @Bean on the overriding methods, but that would be brittle and would require Boot to figure out and maintain which beans are fn-specific, which beans are annotation-specific, and which are general infrastructure required by both programming models. I think that separation should be made in Framework so that it's easy for consumers, including Boot, to enable the features they want without having to know exactly what beans are needed.
Comment From: sdeleuze
I agree it will require some Framework change, we had a dedicated discussion within the team and decided to wait for Spring Framework 6 to handle this.
Comment From: dsyer
For the record, in spring-init we implement this by hard-coding a handful of beans as conditional when they weren't in Spring (or Boot). Currently those are:
"org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping",
"org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter",
"org.springframework.web.method.support.CompositeUriComponentsContributor",
"org.springframework.web.reactive.result.method.annotation.RequestMappingHandlerAdapter",
"org.springframework.web.reactive.result.method.annotation.RequestMappingHandlerMapping",
"org.springframework.boot.actuate.endpoint.web.reactive.WebFluxEndpointHandlerMapping",
"org.springframework.boot.actuate.endpoint.web.reactive.ControllerEndpointHandlerMapping",
"org.springframework.boot.actuate.endpoint.web.servlet.WebMvcEndpointHandlerMapping",
"org.springframework.boot.actuate.endpoint.web.servlet.ControllerEndpointHandlerMapping"