Skip to content

Conversation

@trask
Copy link
Member

@trask trask commented Dec 11, 2025

Now that we have a real configuration API, let's consolidate!

This PR shows end-to-end that we can delete all of the other configuration APIs and bridges.

ConfigProperties still needs to live, but only during SDK autoconfiguration.

Then we can bridge ConfigProperties and use the declarative configuration API everywhere else.

This PR shows the final result.

Planning to break this PR into smaller pieces:

                               ┌─(B)─> AgentInstrumentationConfig (11 PRs) ──> Delete (1 PR)
                               │       - aws, database, redis,                 - AgentInstrumentationConfig,
                               │         messaging, logging,                     (agent) ConfigPropertiesBridge
                               │         graphql-grpc, web, async,
                               │         http, annotations, other
                               │
                               ├─(C)─> Delete AgentConfig (1 PR)
                               │
                               ├─(D)─> CommonConfig (1 PR) ──> CommonConfig (4 PRs) ──> Delete (1 PR)
                               │       - Foundation            - http-clients,          - CommonConfig,
                               │                                 http-servers,            AgentCommonConfig,
                               │                                 database,                EnduserConfig
                               │                                 other
                               │
(A) Foundation (1 PR) ─────────┼─(E)─> ExperimentalConfig (4 PRs) ──> Delete (1 PR)
    - Reverse bridge,          │       - controller-view,             - ExperimentalConfig
      DeclarativeConfigUtil    │         messaging,
                               │         indy, other
                               │
                               ├─(F)─> Extension APIs (3 PRs)
                               │       - IgnoredTypesConfigurer,
                               │         InstrumentationModule,
                               │         AgentExtension
                               │
                               └─(G)─> Spring Boot (1 PR) ──> Spring Boot (5 PRs) ──> Delete (1 PR)
                                       - Foundation           - http-clients,         - InstrumentationConfigUtil,
                                                                http-servers,           (spring) ConfigPropertiesBridge
                                                                database,
                                                                messaging, other

(H) Clean up (1 PR)
    - Delete InstrumentationConfig

@trask trask force-pushed the declarative-configuration-bridge branch from 47b3ed3 to ff7085e Compare December 11, 2025 04:17
@trask
Copy link
Member Author

trask commented Dec 11, 2025

I think the problem with this is that we don't have (or want?) an automatic way to convert system properties to SDK's declarative config (e.g. exporters, etc)

hm.. maybe this could still work(?).. because we'd just be bolting on ConfigProvider.getInstrumentationConfig() after the SDK has already built the OpenTelemetry instance...

@trask trask closed this Dec 11, 2025
@trask trask reopened this Dec 11, 2025
@trask trask force-pushed the declarative-configuration-bridge branch 4 times, most recently from 622372c to 37ee27b Compare December 12, 2025 17:07
trask added 22 commits December 12, 2025 19:08
…onstructor

The DeclarativeConfigUtil.getList().map(HashSet::new).orElse() pattern
produces Optional<HashSet<String>>, but HttpConstants.KNOWN_METHODS is
a Set<String>. Wrapping it in 'new HashSet<>()' fixes the type mismatch.

Fixes compilation errors in:
- AgentServletInstrumenterBuilder
- Servlet2SpanNameExtractor
- HttpUrlConnectionSingletons
- ElasticsearchRestJavaagentInstrumenterFactory
- HttpSpanDecorator (camel-2.20)
- AwsLambdaEventsInstrumenterFactory
1. rxjava-3.0: Fixed import - changed package from v3 to v3_0
   TracingAssembly is in io.opentelemetry.instrumentation.rxjava.v3_0 not v3

2. aws-lambda-events: Updated createInstrumenter calls
   - Removed third parameter (HttpConstants.KNOWN_METHODS)
   - Method signature changed to only accept (OpenTelemetry, String)
   - The known methods are now retrieved internally by the factory
   - Removed unused HttpConstants imports from both v2_2 and v3_11
@trask trask force-pushed the declarative-configuration-bridge branch from eaa45fd to d64f9c7 Compare December 13, 2025 17:38
trask added 13 commits December 13, 2025 10:12
Use 'java' path instead of 'general' path for emit_experimental_telemetry
configuration in NettyServerSingletons to match the client configuration
and properly enable HTTP/2 protocol upgrade events on server spans.
- Fix RuntimeConfigProperties to use EmptyConfigProperties.INSTANCE instead of new
- Make deprecated configure() method default in IgnoredTypesConfigurer interface
- Migrate IgnoredTypesConfigurer implementations to use DeclarativeConfigUtil with GlobalOpenTelemetry
- Add @SuppressWarnings with explanatory comments for deprecated API usage in fallback paths
- Fix spotless formatting in OpenTelemetryAutoConfiguration
@trask trask force-pushed the declarative-configuration-bridge branch from 8af1359 to 9c67113 Compare December 13, 2025 21:15
trask added 12 commits December 13, 2025 13:25
The issue was that AgentTracerProviderConfigurer.maybeEnableLoggingExporter()
was calling GlobalOpenTelemetry.get() during SDK configuration, which caused
GlobalOpenTelemetry to auto-initialize before the agent could call
GlobalOpenTelemetry.set().

Changed to use the ConfigProperties parameter that is already available,
reading otel.javaagent.debug directly from config instead of using
DeclarativeConfigUtil with GlobalOpenTelemetry.get().
The ApplicationLoggingInstrumentationModule.defaultEnabled() method was using
GlobalOpenTelemetry.get() to check if the application logger is enabled, but
this happens very early during agent startup before GlobalOpenTelemetry is
set up. At that point, GlobalOpenTelemetry.get() returns a noop instance that
doesn't have the config, causing the instrumentation to incorrectly apply to
classloaders where ApplicationLoggerBridge.set() was never called.

Reverted to using ConfigProperties which is available earlier during agent
initialization and correctly checks the otel.javaagent.logging property.
@trask trask changed the title Declarative configuration bridge One configuration API to rule them all Dec 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant