Consider simplifying OpenTelemetryAutoConfiguration

[vpavic]

OpenTelemetryAutoConfiguration in its current shape contributes quite a few beans to the application context. In reality, most of those beans aren't likely be used anywhere (outside of contributing to OpenTelemetry bean) and appear to have been registered as beans just for the sake of being overridable (as they're @ConditionalOnMissingBean). However, the same effect (with lesser impact to application context) could have been achieved by having OpenTelemetry @Bean method accepting ObjectProvider arguments for different OTel components it depends on. Consequently, if I'm taking full control and configuring OpenTelemetry bean on my own, I'll still have all those OTel-related beans contributed to the application context.

So my proposal is to look into minimizing the number of OTel-related beans contributed to the application context, ideally reducing it to just OpenTelemetry bean.

More generally, the Actuator appears to me to be getting more and more bulky with time, and I'd like to see its impact on application context to be minimized, where possible.

[wilkinsona]

Duplicates #34023.

[mhalbritter]

After talking about that, we decided to reopen the issue.

This issue (creating beans which are overridable which may then not be used) is a more general problem in most of our auto-configurations. Tackling this in a more general way may require effort in the Spring Framework. Before starting work on that, we should benchmark the impact of unused beans on the application context to assess if this is worth fixing.

[vpavic]

Thanks for taking another look at this and breaking #34023 into several smaller, more focused, issues - I was about to suggest that.

This issue (creating beans which are overridable which may then not be used) is a more general problem in most of our auto-configurations. Tackling this in a more general way may require effort in the Spring Framework.

Maybe I'm missing something, but what's the point of having so many OpenTelemetry components registered as beans in the first place? In order to offer a possibility of customizing some bits of the configuration by consuming user-contributed beans, it isn't really necessary to have those same components registered as beans by auto-configuration.

[mhalbritter]

Most (if not all) of the Spring Boot auto-configurations work in that way. They offer beans which are @ConditionalOnMissingBean so that users can override them. That's why we did it this way for OpenTelemetry, too.

It's technically possible to achieve that customizations without beans by using ObjectProvider, but before refactoring the whole auto-configuration, we want to take a step back and see if this problem can be solved in a more general way.