Provide a mechanism to hide properties in the metadata

[wilkinsona]

#2027 adds support for configuring Bitronix and Atomikos' connection pools via the environment. These pools expose some properties that it doesn't make sense to expose to the environment such as PoolDataSourceBean.failed. We also want to hide PoolDataSource.className as we configure that automatically to use our DirectXADataSource

[snicoll]

We need a way to also disable keys that are set in code that we don't own. Some thoughts:

• @ConfigurationProperty(ignore=true)
• @ConfigurationProperties(prefix="foo", excludeKeys=["foo.key", "foo.sub.bar"])

We could also add an "ignore" attribute to a property to make explicit that it should be ignored (in case of IDEs are trying to do smart things behind our back). In this case, we could ignore any property by simply registering with the ignore flag enabled; when we merge the additional meta-data with the current result, we override the flag.

[philwebb]

Since this is quite an edge-case I think a new annotation might be better. I'm worried that more attributes on @ConfigurationProperties might be confusing. We already have @NestedConfigurationProperty so perhaps something like @IgnoredConfigurationProperty which could be used on the class or a field.

Another option might be to try and extend the additional-spring-configuration-metadata file.

[wilkinsona]

This has come up again in 3.4 when some changes in Oracle UCP have resulted in some new properties appearing in the metadata:

1. spring.datasource.oracleucp.connection-wait-duration
2. spring.datasource.oracleucp.connection-wait-duration-in-millis
3. spring.datasource.oracleucp.hostname-resolver

We don't need both 1 and 2. 3 doesn't make sense at all as it requires an instance of HostnameResolver which can't be created from properties (without custom conversion).

[philwebb]

We discussed this today and we'd like to configure this in an external file (similar to additional-spring-configuration-metadata). This would remove the need for any new public annotations. We'd keep the binder as it is and not try to prevent binding if someone did use an excluded name.

[brabenetz]

I have the problem that a 'property' is shown, where I only have a getter method.
What is the reason that readonly-properties are not excluded automatically?

My first thought was a field annotation like @ Transient for JPA.

[philwebb]

@brabenetz I was under the impression that with filter out properties that only have a setter unless they are collections or nested properties. This line of code should do that. Feel free to raise a new issue with a sample project that replicates the problem if you like and we can take a look.

[mhalbritter]

In https://github.com/mhalbritter/spring-boot/tree/mh/2421-provide-a-mechanism-to-hide-properties-in-the-metadata I've implemented the idea of using a separate file to specify the properties which should be ignored. This file is read by the spring-boot-configuration-processor and the ignored properties are then omitted from the generated spring-configuration-metadata.json file.

The ignore file is called META-INF/ignored-spring-configuration-properties.json and has this structure:

{
  "properties": [
    {
      "name": "my.age"
    }
  ]
}

WDYT?

[wilkinsona]

I like it although I'm not totally sure about the use of a separate file.

I wonder if it would be better to use the existing additional-spring-configuration-metadata.json file. I think we discussed that in the past but I don't recall the reasoning for the separate file. One disadvantage is that it's spreading things out more and, arguably, making it harder to keep track of them. One advantage is that it would allow the additional-… file to continue to have identical structure to the annotation-processor-generated file. That said, if we added support for something like @IgnoredConfigurationProperty in the future then the annotation-processor-generated file would need to declare ignores too.

[snicoll]

+1 for reusing the existing file. We can declare the additional field event if they don’t end up in the generated file.

I wonder if that’s an extension of the deprecation support. If we ignore a property that’s because it’d have been picked up otherwise and we don’t want that. So having the IDE to know that it looks like a property but we don’t want to offer it is useful IMO.

[mhalbritter]

Thanks both. Let's talk in a meeting about this (maybe we recall the reason why we proposed a separate file in the first place), and if we decide to drop the additional file, i'll implement the solution with additional-spring-configuration-metadata.json.

[philwebb]

We discussed this again today and given #2421 (comment) we want to put the filter data inside the existing additional-spring-configuration-metadata.json and have it copied to the generated spring-configuration-metadata.json. We'll also use it to filter out values.

This should give us a situation where the metadata works well with existing IDEs, but there's no loss of information if they work directly with the class files and also need to know what to filter.

[mhalbritter]

I've updated the branch and it now looks like this:

Given this class

@ConfigurationProperties(prefix = "my")
public class MyProperties {
    private String name;
    private int age;

    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return this.age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

and this additional-spring-configuration-metadata.json:

{
  "properties": [
  ],
  "ignored": {
    "properties": [
      {
        "name": "my.age"
      }
    ]
  }
}

the generated spring-configuration-metadata.json looks like this:

{
  "groups": [
    {
      "name": "my",
      "type": "org.example.sb2421.MyProperties",
      "sourceType": "org.example.sb2421.MyProperties"
    }
  ],
  "properties": [
    {
      "name": "my.name",
      "type": "java.lang.String",
      "sourceType": "org.example.sb2421.MyProperties"
    }
  ],
  "hints": [],
  "ignored": {
    "properties": [
      {
        "name": "my.age"
      }
    ]
  }
}

my.age has been removed from the properties array, and the ignored object from additional-spring-configuration-metadata.json has been copied into spring-configuration-metadata.json.