Skip to content

Add @Selector support to the configprops actuator endpoint #24714

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
philwebb opened this issue Jan 8, 2021 · 8 comments
Closed

Add @Selector support to the configprops actuator endpoint #24714

philwebb opened this issue Jan 8, 2021 · 8 comments
Labels
status: superseded An issue that has been superseded by another type: enhancement A general enhancement

Comments

@philwebb
Copy link
Member

philwebb commented Jan 8, 2021

It would be nice if you could limit the output of /actuator/configprops to a specific value in the same way that you can with the environment endpoint.

@philwebb philwebb added the type: enhancement A general enhancement label Jan 8, 2021
@philwebb philwebb added this to the General Backlog milestone Jan 8, 2021
@onobc
Copy link
Contributor

onobc commented Jan 9, 2021

@philwebb I picked this up and wanted to run my thoughts on filtering by you before getting too much further. My plan is to:

Filter by prefix: /actuator/configprops?prefix=<config-props-prefix-goes-here>
Filter by config props simple classname: /actuator/configprops/<config-props-simple-classname-goes-here>

Examples:

  • /actuator/configprops?prefix=spring.kafka
  • /actuator/configprops/ServerProperties

@snicoll
Copy link
Member

snicoll commented Jan 11, 2021

I think it's worth discussing how to filter the data. I don't know what Phil had in mind but if we want to do something similar to /env, I think the selector should be the id of the entity in the result. Unfortunately, this id isn't super easy to remember. I don't think we should be using SeverProperties, in particular, as you may have two cases with the same name.

Given that the prefix is easier to remember (and something that's easier to resonate than a class name), my vote would be the first option in your examples.

@snicoll snicoll added the for: team-attention An issue we'd like other members of the team to review label Jan 11, 2021
@onobc
Copy link
Contributor

onobc commented Jan 11, 2021

Unfortunately, this id isn't super easy to remember.

Yeh that is exactly what I ran into when I started w/ that as the filter.

in particular, as you may have two cases with the same name.

Yes that is true. In that case they would both show up as well w/ what prefix they are mapped to. I added this filter by asking myself what would I want to filter by. Prefix for sure. The properties class is the next thing I think of - KafkaProperties is one I end up looking at multiple times a day for example. Because I seem to find my way into those configprops classes in my editor I am familiar w/ the class name so it seemed like a good candidate. For me, they are both valuable.

Also, I have some screenshots to show the filtered results if that helps at all.

@philwebb
Copy link
Member Author

Thanks for looking at this @Bono007. I added the issue as a note to myself so it's a bit light on details.

I think most users will probably want to filter on the property prefix, since that's the most user-facing value. I would suggest trying /actuator/configprops/<prefix> and then filtering the results so that only configuration properties starting with the given prefix are shown.

@onobc
Copy link
Contributor

onobc commented Jan 12, 2021

@snicoll @philwebb I will get the updates in w/in the next 24-48 hrs

@onobc
Copy link
Contributor

onobc commented Jan 13, 2021

@snicoll @philwebb I pivoted the merge request to filter only by prefix and also added the docs.

@philwebb philwebb removed the for: team-attention An issue we'd like other members of the team to review label Jan 13, 2021
@philwebb
Copy link
Member Author

Thanks @Bono007!

@wilkinsona
Copy link
Member

Closing in favour of #24718.

@wilkinsona wilkinsona removed this from the General Backlog milestone Jan 15, 2021
@wilkinsona wilkinsona added the status: superseded An issue that has been superseded by another label Jan 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants