Skip to content
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

return-body-on-create and return-body-on-update shown as deprecated [DATAREST-660] #1037

Closed
spring-projects-issues opened this issue Aug 26, 2015 · 3 comments
Assignees
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: bug A general bug

Comments

@spring-projects-issues
Copy link

spring-projects-issues commented Aug 26, 2015

Stéphane Nicoll opened DATAREST-660 and commented

Commit 5486712b changed some method signatures to use a more fluent API and flagged the regular getter as deprecated.

Spring Boot only supports regular getter/setter pair so the @Deprecated flag is interpreted as a deprecated property (while it's not in practice). I would advise to rework this commit if possible as any class flagged @ConfigurationProperites should expose regular java bean properties for now.

Note that this a good example of how complex it would be to support a more fluent API in Spring Boot (if we ever decided to do so).


Affects: 2.4 RC1 (Gosling)

@spring-projects-issues
Copy link
Author

spring-projects-issues commented Aug 28, 2015

Oliver Drotbohm commented

I think you're misinterpreting the commit. The accessor methods are not (and never have been actually) intended for configuration. They're used by controllers to lookup configuration values. The changed introduced the Accept header starting to play a role in the decision so the deprecation is basically a hint to clients that they need to use the new method taking a String to get a correct result.

I am wondering why the property inspection mechanism considers the getters at all, as for the configuration the setters should relevant, shouldn't they? That said, I can of course go ahead and outright remove the relevant is… methods as it's considered internal API anyway

@spring-projects-issues
Copy link
Author

spring-projects-issues commented Aug 31, 2015

Oliver Drotbohm commented

Apparently removing the getters doesn't work as this would prevent the properties from being discovered by the Boot @ConfigurationProperties handling.

As it's essentially Spring Boot turning this into a config properties class one option would be to extend RepositoryRestConfiguration in Spring Boot's REST auto-configuration and add/override the missing setters, if it really insists them to be in place

@spring-projects-issues
Copy link
Author

spring-projects-issues commented Feb 22, 2016

Stéphane Nicoll commented

We no longer expose that object directly in Spring Boot so I think this issue is no longer relevant

@spring-projects-issues spring-projects-issues added type: bug A general bug status: declined A suggestion or change that we don't feel we should currently apply labels Dec 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants