Skip to content

Move "*.enabled" keys from metadata to dedicated @ConfigurationProperties bean #46220

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 1 commit into from

Conversation

quaff
Copy link
Contributor

@quaff quaff commented Jun 27, 2025

IIRC, this is the recommended way.

…rties` bean

Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 27, 2025
@snicoll
Copy link
Member

snicoll commented Jun 27, 2025

IIRC, this is the recommended way.

What makes you think that?

@snicoll snicoll added the status: waiting-for-feedback We need additional information before we can continue label Jun 27, 2025
@philwebb
Copy link
Member

I don't think we really have a single way to deal with enabled properties, and I'm not really sure that we should. I think there's at least one or two that only in the metadata because we don't have a @ConfigurationProperties class for them.

All things considered, I think we should leave things as they are for now.

Thanks anyway for the PR.

@philwebb philwebb closed this Jun 27, 2025
@philwebb philwebb added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged labels Jun 27, 2025
@quaff
Copy link
Contributor Author

quaff commented Jun 30, 2025

IIRC, this is the recommended way.

What makes you think that?

See #43886 (comment)

@wilkinsona prefer creating new @ConfigurationProperties bean over hand-written metadata, this PR reuse existing @ConfigurationProperties bean.

@wilkinsona
Copy link
Member

That was a preference in a specific situation rather than a rule. Thanks again for the PR but, generally speaking, I think it's better to leave the introduction of stylistic changes that cut across the whole codebase to the core team.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants