Skip to content

Add Support for Resolving Property Values in @RequestMapping(value) #361

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

Closed
kevinconaway opened this issue Jun 22, 2015 · 5 comments
Closed
Assignees
Labels
in: core Core parts of the project
Milestone

Comments

@kevinconaway
Copy link

The @RequestMapping(value) annotation supports property values for dynamically specifying the endpoint value, like @RequestMapping(value="${some.request.mapping})

I am using the Springfox project to document my API and I would like to be able to add a Link to the Swagger2 documentation in my API:

I'm adding a link to a resource via:
resource.add(linkTo(methodOn(Swagger2Controller.class).getDocumentation(null)).withRel("swagger.json"));

and the resuling link looks like:

http://localhost:8080/api/${springfox.documentation.swagger.v2.path:/v2/api-docs}

@jghiloni
Copy link

I'd like to throw my support behind this as well

gregturn pushed a commit that referenced this issue Jun 15, 2017
gregturn pushed a commit that referenced this issue Jun 15, 2017
gregturn pushed a commit that referenced this issue Jun 15, 2017
gregturn pushed a commit that referenced this issue Jun 15, 2017
gregturn pushed a commit that referenced this issue Jun 15, 2017
gregturn pushed a commit that referenced this issue Jun 16, 2017
gregturn pushed a commit that referenced this issue Jul 31, 2017
gregturn pushed a commit that referenced this issue Aug 28, 2017
@joeybic
Copy link

joeybic commented Sep 6, 2018

Is anybody still working on this? I know it's been more than a year, but it'd be super helpful if this worked...

gregturn pushed a commit that referenced this issue Feb 6, 2019
gregturn pushed a commit that referenced this issue Feb 6, 2019
gregturn pushed a commit that referenced this issue Feb 6, 2019
gregturn pushed a commit that referenced this issue Feb 6, 2019
@huehnerlady
Copy link

@gregturn Any update on this? It would be very important to us, will this be fixed soon? It is hanging for 3 years now 😞

odrotbohm pushed a commit that referenced this issue Jul 27, 2020
We now pipe the detected mapping through the PropertyResolver exposed by the ApplicationContext's Environment.

Original pull request: #1328.
odrotbohm added a commit that referenced this issue Jul 27, 2020
Made implementation class package protected to not expose it. Avoid the use of Optional for hot code paths. Removed factory method as we only use the type internally anyway.

Removed test customizations as the discoverer is now just leniently opting out if not ApplicationContext can be found.

Original pull request: #1328.
@odrotbohm
Copy link
Member

Resolved by #1328

@odrotbohm odrotbohm added this to the 1.2.0-M1 milestone Jul 27, 2020
@odrotbohm odrotbohm self-assigned this Jul 27, 2020
@odrotbohm odrotbohm added in: core Core parts of the project and removed process: in progress labels Jul 27, 2020
odrotbohm added a commit that referenced this issue Jul 27, 2020
Moved PropertyResolvingMappingDiscoverer into server.core package. Unified MappingDiscoverer arrangement in WebHandler and use it from there. Deprecated AnnotationBasedMappingDiscoverer to be able to make it package protected in 1.3.
@mirceade
Copy link

mirceade commented Mar 8, 2022

I don't get it, this doesn't really work in 1.4.0 with Kotlin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Core parts of the project
Projects
None yet
Development

No branches or pull requests

7 participants