You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am inclined to go down a slightly different route than what's suggested in #452. Here's what's actually causing the issue: when PagedResourcesAssembler is resolved for method injection, our HanderMethodArgumentResolver currently equips it with a default URI that is the one created when pointing to the method that is currently invoked. In the course of that, optional request parameters are dropped as we don't consider the request parameters when expanding those potentially optional parameters.
That said, I think wen can just skip the pre-computation entirely as PagedResourcesAssembler will fall back to use the current request's URI as the base for the links to be created. If controller methods want to use anything but that, they're free to calculate that URI and hand a Link into an overload of ….toModel(…) explicitly. I just briefly checked whether that removal works and except a test case checking for some internal state of PRA no test cases fail, also not in Spring Data REST.
I am inclined to back-port this into 2.4 (i.e. Spring Boot 2.4) as well as it's a rather young branch and we can easily tweak things back in case this causes trouble. For Neumann (SR7 approaching) I'd leave the decision up for @mp911de.
We now avoid the pre-computation of the base URI in PagedResourceAssemblerArgumentResolver as the actual assembler will fall back to using the URI of the current request by default anyway. The latter makes sure that request parameters, that are contained in the original requests appear in links created. If a controller wants to deviate from that behavior, they can create a dedicated link themselves and hand that to the assembler explicitly.
FixesGH-2173, GH-452.
We now avoid the pre-computation of the base URI in PagedResourceAssemblerArgumentResolver as the actual assembler will fall back to using the URI of the current request by default anyway. The latter makes sure that request parameters, that are contained in the original requests appear in links created. If a controller wants to deviate from that behavior, they can create a dedicated link themselves and hand that to the assembler explicitly.
FixesGH-2173, GH-452.
Réda Housni Alaoui opened DATACMNS-1757 and commented
Let's consider the following test:
The described test fails because the generate response body is:
The navigation links hold the correct page parameters, but they are missing request parameter text.
Affects: 2.4 M1 (2020.0.0)
Referenced from: pull request #452
The text was updated successfully, but these errors were encountered: