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 <aber...@apache.org> 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 <rschm...@apache.org> wrote: > > > What impact will this have on the project's dependency structure? > > > > On Sun, Aug 3, 2025 at 7:35 AM Arturo Bernal <aber...@apache.org> 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 > > > > > >
