NonRootBeanPostProcessor eagerly depends on MeterRegistry which can have undesirable side effects

[bruto1]

Expected Behavior

All Meter binders, filters, customizers present in Spring context applied timely and correctly

Actual Behavior

After updating Temporal libs from 1.22.3 to 1.28.4 NonRootBeanPostProcessor, via Scope in MetricsScopeAutoConfiguration, caused MeterRegistry to be instantiated before MeterRegistryPostProcessor is added to bean factory's postprocessors and thus a lot of code relying on meter binders (like JvmMetricsAutoConfiguration) or Micrometer's globalRegistry containing all meter registries (which are added to it by said MeterRegistryPostProcessor) is unable to create Meters.

This happens because NonRootBeanPostProcessor is instantiated in the same loop as MeterRegistryPostProcessor and they're only added to bean factory later

Spring detects such situations and writes the following log message to make the user aware of them:

WARN 27112 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'prometheusMeterRegistry' of type [io.micrometer.prometheusmetrics.PrometheusMeterRegistry] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor [nonRootBeanPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.  

So one or both dependencies (NonRootBeanPostProcessor on scope and scope on MeterRegistry) need to be made lazy

Steps to Reproduce the Problem

You can take the repro case from here: spring-projects/spring-boot#22926 (comment) - it's the same problem that occurred with a different set of libraries

Specifications

• Version: 1.28.4
• Platform: all

[Quinn-With-Two-Ns]

Hi, can you please included a self contained minimal reproduction with the Temporal SDK. The linked issue does not use the Temporal SDK, thank you.

[ajgassner]

Could be caused by spring-projects/spring-boot#45202

[kurtinaitis]

Working correctly with version 1.24.2

[bruto1]

@kurtinaitis that's because the class causing this problem was added in 1.28.0: https://github.com/temporalio/sdk-java/releases/tag/v1.28.0
c6375d6#diff-9114a5eefb4b2ce6e22451e2650bbf67168630cdf3bc2bf0689fbccda393fed6

[ragutsky]

Metrics exposed by Micrometer disappeared when I updated to 1.28.0 version.

I got the following message during bootstrap:

Bean 'io.temporal.spring.boot.autoconfigure.NonRootNamespaceAutoConfiguration' of type [io.temporal.spring.boot.autoconfigure.NonRootNamespaceAutoConfiguration$$SpringCGLIB$$0] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). The currently created BeanPostProcessor [nonRootBeanPostProcessor] is declared through a non-static factory method on that class; consider declaring it as static instead.

Spring expects BeanPostProcessor beans to be registered very early in the context lifecycle. Defining one via a non-static method forces early instantiation of the configuration class, which can cause:

• The configuration class itself and its beans to miss being proxied
• Other post-processors to be applied too late

Temporary workaround worked:

1. Added

spring:
  autoconfigure:
    exclude: io.temporal.spring.boot.autoconfigure.NonRootNamespaceAutoConfiguration

2. Copy pasted NonRootNamespaceAutoConfiguration and defined NonRootBeanPostProcessor via a static method:

@Bean
public static NonRootBeanPostProcessor nonRootBeanPostProcessor(...) {
  ...
}

[seanb4t]

Definitely buggy - needs to be resolved.