Values for 'management.endpoints.web.exposure'

[AlexFalappa]

It might make sense to add values hints and any provider to management.endpoints.web.exposure.include and management.endpoints.web.exposure.exclude configuration properties.

The hinted values are the basic available actuators endpoint ids plus *.

This way IDEs could help building the comma separated list of actuator endpoints to hide/expose providing completion on endpoints names. For example I have added such support to NetBeans SpringBoot plugin in commit AlexFalappa/nb-springboot@3fb9478

Such type of hint is similar to that for management.health.status.order configuration property of type List<String>.

Feel free to also backport to 2.1.x line if it makes sense.

[snicoll]

Thanks for the PR @AlexFalappa. You're right that we could provide completion for endpoint IDs there. This list can apply to JMX exposure as well which makes me think there's quite a repetition in values (and endpoints defined outside of Spring Boot could not be documented that way). This makes me wonder how we can improve the metadata syntax to avoid the duplication.

[philwebb]

External jars can also contribute endpoints so we need to find a way for the list to be extended by them.

[AlexFalappa]

@snicoll you are right the same would plainly apply to the JMX endpoint exposure.

@philwebb would merging of hints lists suffice ? Looking at the code in org.springframework.boot.configurationmetadata.SimpleConfigurationMetadataRepository.include(ConfigurationMetadataRepository repository) metadata definitions are not overrided, the first one wins.

If list merging were in place external jars could simply define in additional-spring-configuration-metadata.json their additional hint values under management.endpoints.web.exposure.include (and other properties as well).

Just thinking out loud, I haven't carefully thought of all the implications of configuration metadata merge-instead-of-replace logic.

[snicoll]

@philwebb absolutely, that's what I meant by "and endpoints defined outside of Spring Boot could not be documented that way"

Just thinking out loud, I haven't carefully thought of all the implications of configuration metadata merge-instead-of-replace logic.

We'd have to do something like that but we can't reuse the existing mechanism IMO. Other IDEs have dedicated code and it's not a requirement to use SimpleConfigurationMetadataRepository. I guess it's a contribution mechanism we have to investigate.

[AlexFalappa]

Just added hints values for JMX endpoints as well if you intend to go down the repeated values road in the short term and think about a more comprehensive solution after.

Squash at will.

[snicoll]

Thanks again for the PR and the update @AlexFalappa. We've come to the conclusion that the current situation is not ideal and decided to remove hints from our metadata altogether.

We'd like to tackle this problem differently, see #18408