Re: Early-stage Observability Integration
Ryan, httpclient5-observation is a bolt-on: core/client just offer public hooks—no static linkage, no reflection. Interceptors get wired at build-time; if the module isn’t on the classpath, nothing gets loaded. Happy to revisit TRACE/INFO thresholds once this lands. Arturo On Wed, Aug 6, 2025 at 8:24 PM Ryan Schmitt wrote: > Will core/client/etc integrate with httpclient5-observation using > reflection, or will they not even know about that module? Sometimes > "optional" modules are implemented using static linkage rather than > reflection, which I think leans a little too heavily on lazy classloading > in a way that can interfere with tooling like SpotBugs, ProGuard, Graal > AOT, and so forth. > > On a tangential note, I really think the debug logging in HttpClient needs > improvement. For starters, I would move the wire logging to TRACE and > upgrade some statements to INFO (particularly things related to connection > lifecycle management, connections being established and discarded, and > intermittent connection pooling statistics). > > On Wed, Aug 6, 2025 at 10:34 AM Arturo Bernal wrote: > > > The Micrometer / OTel stack is confined to the new > httpclient5-observation > > artifact, leaving core, cache, fluent and all other existing modules > > untouched. > > > > Since those dependencies are declared optional, they do not flow > > transitively, so current users experience zero binary or runtime change > > unless they opt in. > > > > > > > > Arturo > > > > > > On Wed, 6 Aug 2025 at 7:11 PM, Ryan Schmitt wrote: > > > > > What impact will this have on the project's dependency structure? > > > > > > On Sun, Aug 3, 2025 at 7:35 AM Arturo Bernal > wrote: > > > > > > > Hi all, > > > > I’m exploring adding optional OpenTelemetry & Micrometer support to > > > > HttpClient > > > > It’ll be fully configurable via the user’s ObservationRegistry and > OTel > > > > settings. > > > > Details are TBD, but the goal is zero-boilerplate tracing & metrics. > > > > > > > > Would love quick feedback on module placement and overall approach. > > > > > > > > Thanks! > > > > Arturo > > > > > > > > > >
Re: Early-stage Observability Integration
Will core/client/etc integrate with httpclient5-observation using reflection, or will they not even know about that module? Sometimes "optional" modules are implemented using static linkage rather than reflection, which I think leans a little too heavily on lazy classloading in a way that can interfere with tooling like SpotBugs, ProGuard, Graal AOT, and so forth. On a tangential note, I really think the debug logging in HttpClient needs improvement. For starters, I would move the wire logging to TRACE and upgrade some statements to INFO (particularly things related to connection lifecycle management, connections being established and discarded, and intermittent connection pooling statistics). On Wed, Aug 6, 2025 at 10:34 AM Arturo Bernal wrote: > The Micrometer / OTel stack is confined to the new httpclient5-observation > artifact, leaving core, cache, fluent and all other existing modules > untouched. > > Since those dependencies are declared optional, they do not flow > transitively, so current users experience zero binary or runtime change > unless they opt in. > > > > Arturo > > > On Wed, 6 Aug 2025 at 7:11 PM, Ryan Schmitt wrote: > > > What impact will this have on the project's dependency structure? > > > > On Sun, Aug 3, 2025 at 7:35 AM Arturo Bernal wrote: > > > > > Hi all, > > > I’m exploring adding optional OpenTelemetry & Micrometer support to > > > HttpClient > > > It’ll be fully configurable via the user’s ObservationRegistry and OTel > > > settings. > > > Details are TBD, but the goal is zero-boilerplate tracing & metrics. > > > > > > Would love quick feedback on module placement and overall approach. > > > > > > Thanks! > > > Arturo > > > > > >
Re: Early-stage Observability Integration
The Micrometer / OTel stack is confined to the new httpclient5-observation artifact, leaving core, cache, fluent and all other existing modules untouched. Since those dependencies are declared optional, they do not flow transitively, so current users experience zero binary or runtime change unless they opt in. Arturo On Wed, 6 Aug 2025 at 7:11 PM, Ryan Schmitt wrote: > What impact will this have on the project's dependency structure? > > On Sun, Aug 3, 2025 at 7:35 AM Arturo Bernal wrote: > > > Hi all, > > I’m exploring adding optional OpenTelemetry & Micrometer support to > > HttpClient > > It’ll be fully configurable via the user’s ObservationRegistry and OTel > > settings. > > Details are TBD, but the goal is zero-boilerplate tracing & metrics. > > > > Would love quick feedback on module placement and overall approach. > > > > Thanks! > > Arturo > > >
Re: Early-stage Observability Integration
What impact will this have on the project's dependency structure? On Sun, Aug 3, 2025 at 7:35 AM Arturo Bernal wrote: > Hi all, > I’m exploring adding optional OpenTelemetry & Micrometer support to > HttpClient > It’ll be fully configurable via the user’s ObservationRegistry and OTel > settings. > Details are TBD, but the goal is zero-boilerplate tracing & metrics. > > Would love quick feedback on module placement and overall approach. > > Thanks! > Arturo >
Re: Early-stage Observability Integration
On 2025-08-03 16:35, Arturo Bernal wrote: Hi all, I’m exploring adding optional OpenTelemetry & Micrometer support to HttpClient It’ll be fully configurable via the user’s ObservationRegistry and OTel settings. Details are TBD, but the goal is zero-boilerplate tracing & metrics. Would love quick feedback on module placement and overall approach. Thanks! Arturo Arturo As long as the default implementation can be null or no-op, go for it. I would also put OpenTelemetry & Micrometer specific into a separate module like caching. Oleg - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Early-stage Observability Integration
Metrics and traces answer different questions—Micrometer’s rich registry ecosystem handles “how much/how often,” while OpenTelemetry owns end-to-end causality. Micrometer’s Observation API gives us a single façade: one hook in HttpClient, pluggable handlers fan out to Prometheus stats and OTLP spans. Arturo On Sun, 3 Aug 2025 at 4:43 PM, Gary Gregory wrote: > Why both? Or is there an Java API facade that covers both like JDBC, JPA, > JMS, Logging and so on? > > Gary > > On Sun, Aug 3, 2025, 10:35 Arturo Bernal wrote: > > > Hi all, > > I’m exploring adding optional OpenTelemetry & Micrometer support to > > HttpClient > > It’ll be fully configurable via the user’s ObservationRegistry and OTel > > settings. > > Details are TBD, but the goal is zero-boilerplate tracing & metrics. > > > > Would love quick feedback on module placement and overall approach. > > > > Thanks! > > Arturo > > >
Re: Early-stage Observability Integration
Why both? Or is there an Java API facade that covers both like JDBC, JPA, JMS, Logging and so on? Gary On Sun, Aug 3, 2025, 10:35 Arturo Bernal wrote: > Hi all, > I’m exploring adding optional OpenTelemetry & Micrometer support to > HttpClient > It’ll be fully configurable via the user’s ObservationRegistry and OTel > settings. > Details are TBD, but the goal is zero-boilerplate tracing & metrics. > > Would love quick feedback on module placement and overall approach. > > Thanks! > Arturo >
