Skip to content

Generate or provide metadata for externally provided configuration properties used with variable prefixes #19500

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
cachescrubber opened this issue Dec 31, 2019 · 4 comments
Labels
status: duplicate A duplicate of another issue

Comments

@cachescrubber
Copy link
Contributor

I use the configuration properties feature to bind properties multiple times using different prefixes which are dynamic in nature.

@ConfigurationProperties(prefix = "client-a")
@Bean
public MyClientProperties clientAproperties() {
  return new  MyClientProperties();
}

@ConfigurationProperties(prefix = "client-b")
@Bean
public MyClientProperties clientBproperties() {
  return new  MyClientProperties();
}

As long as the MyClientProperties class is local to my spring-boot project, the spring-boot-configuration-processor is able to generate metadata for each prefix I use. In particular, the description and defaultValue metatdata is extracted from the field level javadoc of the class:

public class MyClientProperties {
  /**
   * Web service remote endpoint url
   */
  public String endpoint = "http://localhost:8080/services";
...
}

The generated metadata

    {
      "name": "client-a.endpoint",
      "type": "java.lang.String",
      "description": "Web service remote endpoint url",
      "sourceType": "com.example.client.MyClientProperties",
      "defaultValue": "http:\/\/localhost:8080\/services"
    },
...
    {
      "name": "client-b.endpoint",
      "type": "java.lang.String",
      "description": "Web service remote endpoint url",
      "sourceType": "com.example.client.MyClientProperties",
      "defaultValue": "http:\/\/localhost:8080\/services"
    },

This changes as soon as the class is moved to an external jar dependency in order to be shared among several projects and the spring-boot-configuration-processor has no access to the source code of the properties type. The description and defaultValue metadata is no longer available.

    {
      "name": "client-a.endpoint",
      "type": "java.lang.String",
      "sourceType": "com.example.client.MyClientProperties"
    },
...
    {
      "name": "client-b.endpoint",
      "type": "java.lang.String",
      "sourceType": "com.example.client.MyClientProperties"
    },

If MyClientProperties would be used with a fixed prefix only, I could run the spring-boot-configuration-processor within the external jar module and package the generated metatdata.json file. The generated metadata would be visible in the context of the consuming spring-boot application under the my-client prefix.

@@ConfigurationProperties(prefix = "my-client")
public class MyClientProperties {
...
}

What I need is a mechanism to access the description and defaultValue metatdata from the externally provided properties class below the dynamic prefixes chosen by the consuming spring-boot application.

Note: I submited a question at StackOverflow, but in the meantime I think this is most likely an enhancement request.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Dec 31, 2019
@cachescrubber
Copy link
Contributor Author

nested configuration properties are another use-case.

public class MyApplicationProperties {

  @NestedConfigurationProperty
  private MyClientProperties client;

@knoobie
Copy link

knoobie commented Dec 31, 2019

Please take a look at the official documentation, it's well written there.
Edit: Hint - you have to add the spring-boot-configuration-processor as a optional dependency to your jar containing the configuration

@snicoll
Copy link
Member

snicoll commented Dec 31, 2019

@knoobie thanks for trying to help but @cachescrubber is trying to generate metadata content from an external jar.

This is effectively a duplicate of #18366

@snicoll snicoll closed this as completed Dec 31, 2019
@snicoll snicoll added status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged labels Dec 31, 2019
@cachescrubber
Copy link
Contributor Author

@snicoll Thx. My bad, I missed #18366. I'll update StackOverflow accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

4 participants