Spring Data Rest needs to take a RequestMappingInfo and modify the produces condition. It's currently not possible to do this because the required constructor is private.
I think that constructor either needs to be public, or we need some with... methods that return new instances with updated values (similar to addCustomCondition.
Comment From: philwebb
Relates to #26415
Comment From: rstoyanchev
RequestMappingInfo has a builder which is why the public constructors are deprecated. We can add a .mutate() instance method on RequestMappingInfo that gives a Builder pre-populated with the content of the instance. Does that sound okay? What exactly needs to be changed on the produces condition, perhaps we can tailor the Builder even better to that somehow?
Comment From: philwebb
We probably need some input from @odrotbohm. Currently the system looks quite flexible, it takes the ProducesRequestCondition and calls a protected method that can adapt it. You can see the code in BasePathAwareHandlerMapping.
We can add a .mutate() instance method on RequestMappingInfo that gives a Builder pre-populated with the content of the instance
That might be an option, but there's currently no builder methods that take the ProducesRequestCondition objects. There's only produces(String... produces).
Comment From: rstoyanchev
There is an issue in the referenced code since the RequestMapingInfo may have a PathPatternsRequestCondition instead of a PatternsRequestCondition. I'll add a .mutate() method on RequestMappingInfo to support the use case of changing it.
Comment From: philwebb
Unfortunately the mutate() build won't allow us to change the ProducesRequestCondition. It only has a produces(String...) version. I think we need a version that will allow us to set the ProducesRequestCondition directly.
Either that, or we need to change the BasePathAwareHandlerMapping contract.
Comment From: odrotbohm
I have a fix ready that customizes the ProducesCondition and then extracts the media types to pass them into the produces(…) method. This looks like a bit of extra work but does the trick for now. Just waiting for @mp911de decision on when we can actually merge this as it requires Spring Data to upgrade to 5.3.4 snapshots.