The current recommendation to add a reactive messaging HandlerMethodArgumentResolver is to add a preProcess hook.
Spring MVC provides WebMvcConfigurer.addArgumentResolvers which allows configuring HandlerMethodArgumentResolver. WebFlux provides WebFluxConfigurer.configureArgumentResolvers which allows configuring HandlerMethodArgumentResolver. These were provided, presumably, because there were enough people customizing them that Framework decided to provide a first class hook to modify it. I believe the same support should be added to reactive messaging.
Comment From: rstoyanchev
It wouldn't be a one-off configuration hook. I suppose what you're suggesting is an @EnableRSocket setup along with RSocketConfigurer callbacks, as in WebMvc and WebFlux?
Comment From: rwinch
I suppose what you're suggesting is an @EnableRSocket setup along with RSocketConfigurer callbacks, as in WebMvc and WebFlux?
Yes that is what I was thinking.
Comment From: joshlong
I would love to see this land, if possible.
Comment From: jhoeller
@rstoyanchev If something along these lines is in consideration, we could do it for 5.3 RC1 still...
Comment From: rstoyanchev
The config would be RSocketMessageHandler and RSocketStrategies beans along with RSocketConfigurer exposing argument resolvers, return value handlers, Validator, and ConversionService for configuration. The remaining properties on RSocketMessageHandler can be set via RSocketStrategies.
On the Boot side there are currently customizers for RSocketStrategies and RSocketMessageHandler which covers everything that is needed so what extra value does RSocketConfigurer add?
For Encoder, Decoder, RouteMatcher, and MetadataExtractor (the most common ones to customize I believe) the RSocketStrategies customizer is perfectly adequate. For what remains, argument resolvers, return value handlers, Validator, and ConversionService having an RSocketConfigurer would be slightly nicer than setting the same on an RSocketMessageHandler through a customizer but also with the added ambiguity of having multiple ways to do the same.
More broadly my concern is that RSocket has a wider range of possible setup scenarios. I could use RSocketMessageHandler for client side handling of messages from a server. This means potentially more than one, or even more than two RSocketMessageHandler instances in one application. I could create those programmatically with manual registration of handlers, or I could declare them in Spring configuration customized with handler predicates for targeting different subsets of controllers.
I feel we'd be adding a layer around what amounts to trivial configuration but also make things more opaque while making it harder to provide flexibility or imagine other possibilities. So unless I'm missing some benefit I'd rather keep the current arrangement where it's easy to put things together manually with framework only and where pretty much nothing is missing in Boot.
Comment From: rstoyanchev
Team Decision: We'll close this for now with the above as context.