Health (and Metrics and other) endpoints could have an explicit registry API to support child contexts

[dsyer]

It's not a common use case, but since the actuator endpoints all live naturally in the "main" context, when an application adds a child context it is sort of orphaned, and none of its beans get included in metrics or health checks. Example: child context adds a new DataSource, but it won't show up in the health indicators for the app.

The only way I see to provide this is to have a registry API that is a bean in the main context, and then the child context can autowire it and register things (e.g. a health indicator, public metrics, info set).

Spring Cloud Stream already has a version of a solution, but we need something that others can use.

See also #5196

[wilkinsona]

The mappings endpoint is a special case of this. When the management port is set, the actuator's own mappings disappear from the endpoint as they're in the child management context while the endpoint itself remains in the parent.

[wilkinsona]

On further inspection, the mappings endpoint isn't really a special case here. For example, the beans endpoint also has a similar problem. When the management port is set, the beans in the management context (either new ones or those that move from the main application context into the child) aren't included in the output. Moving the endpoint down into the management context doesn't help as then the endpoint is no longer discovered.

[philwebb]

Adding context hierarchy support will add a lot of complexity and I'm not sure we currently have the cycles to do it justice. I'd prefer to keep the actuator code simple for now so I'm going to close this one. We can re-open it in the future if we think hierarchy support is really necessary.