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

Produce metadata for configuration values to improve IDE support for configuration files #33591

Closed
frode-carlsen opened this issue Sep 25, 2024 · 1 comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply

Comments

@frode-carlsen
Copy link

Spring Boot has a feature that allows producing metadata automatically from files annotated with @ConfigurationProperties, that then can be used by IDEs such as Intellij to flag used/unused configuration variables in configuration files (e.g. yaml or properties). This helps ensure proper usage, documentation, and allows cleaning up configuration values that no longer are in effect (particularly valuable in large systems). This feature is opted-in to using the "spring-boot-configuration-processor" annotation processor.

However, there are other useful ways to configure Spring beans, such as through directly referencing @value, which isn't/can't be supported by this (ref spring-projects/spring-boot#42429). It would be greatly helpful if Spring Framework could support such an extension to the quality of configuration.

@bclozel
Copy link
Member

bclozel commented Sep 25, 2024

I'm not sure I fully understand. So you would like Spring Framework to do the following?

  1. provide an annotation processor that scans for @Value annotations
  2. extract information from @Value annotations to detect property-like values
  3. write this information into the Spring Boot metadata format to get "Spring Boot-like" IDE integration

I'm not really sure this would make sense.

The Spring Boot configuration metadata spec is really operating under Spring Boot's constraints. In many cases, we won't be able to actually trace a source sourceType nor a proper type for the value, and definitely not a description.

@Value annotations can be quite flexible and provide different default values at the injection point, and even SpEL expressions.

I understand that you would like to track those in your application, but I believe this is better handled at the source and under specific constraints. Here, we would be doing so at the injection point level. If you would like to track down the usage of those values, I believe this can be only performed through an bean post processor: many @Value annotation may not be processed in the end, depending on the scanning and bean arrangement of your application.

Also, how would values be detected as unused? Should the IDE issue a warning of some sort? Shouldn't we highlight differences between the runtime environment provided to the application and runtime @Value usage?

I think that Spring Framework writing metadata for a format it's not defining itself and tricking IDEs into thinking that Framework is providing Spring Boot configuration properties is misguided. I sympathize with the problem you're facing, but maybe this should be handled in a different way?

I'm closing this issue as we don't want to implement this feature.

@bclozel bclozel closed this as not planned Won't fix, can't repro, duplicate, stale Sep 25, 2024
@bclozel bclozel added status: declined A suggestion or change that we don't feel we should currently apply in: core Issues in core modules (aop, beans, core, context, expression) and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

3 participants