-
Notifications
You must be signed in to change notification settings - Fork 38.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MvcUriComponentsBuilder should resolve property placeholders in request mapping paths #26795
Comments
String s = MvcUriComponentsBuilder.fromController(MyController.class).build().toUriString();
s = valueResolver.resolveStringValue(s);
UriComponents uriComponents = UriComponentsBuilder.fromUriString(s)... |
Thank you for the suggested workaround! |
Hi @rstoyanchev I'd like to work on this. I'm going through the code, will raise a PR soon. |
Have raised this Draft PR. Please review the approach and provide your feedback. Working on test cases. |
This commit makes sure to resolve placeholders in request mappings using the EmbeddedValueResolver of the current WebApplicationContext. To avoid retrieving the context too often, we check for the presence of the standard placeholder prefix. Closes spring-projectsgh-26795
I'm using Spring Framework 5.3.4 with Spring Boot 2.4.3.
I have a controller declared in this way:
So, the property
saml.sp.controller-base-mapping
is externalized inapplication.properties
file: if its value issp
, this should be equivalent to:@RequestMapping("sp")
. And indeed Spring Web MVC handles this well.However, if I then use
MvcUriComponentsBuilder
to retrieve the corresponding URL:This returns a
UriComponents
of:http://localhost:8081/${saml.sp.controller-base-mapping}
First problem: I would have expected the externalized property to be already resolved (so to get
http://localhost:8081/sp
), because this should be an expansion mechanism that comes BEFORE path variable expansion.Indeed (and here comes the second problem), if I try to do:
I then get a
UriComponents
of:http://localhost:8081/$sp
This is somewhat expected, since path variable expansion is another story and does not use the "$" marker.
The text was updated successfully, but these errors were encountered: