Bug: Apache transport deadlock in concurrent use case

[cstamas]

Make sure the class SSLConnectionSocketFactory is initialized early, instead lazily in ConcurrentHashMap.computeIfAbsent, as latter may cause deadlock.

Refs:

• @QuarkusTest bootstrap deadlocks during parallel deployment-dependency resolution quarkusio/quarkus#55317
• Pre-init Maven resolver HTTP transport classes to avoid class loading deadlock quarkusio/quarkus#55345

[gnodet]

Clean, well-targeted fix for a real deadlock — the pattern (eager class initialization to avoid the documented ConcurrentHashMap.computeIfAbsent hazard) is sound and well-established.

Evaluation:

• Correctness: The JVM guarantees GlobalState.<clinit> completes before any static/instance members are used, so SSLConnectionSocketFactory is fully initialized before computeIfAbsent is ever reached.
• Sufficiency: A single call to getDefaultHostnameVerifier() triggers SSLConnectionSocketFactory.<clinit>, which initializes the class once. All three usage points (lines 153, 166, 190) then access an already-initialized class.
• Scope: Minimal, focused change — exactly what's needed.
• Tests: No tests added, but acceptable — class-initialization deadlocks are inherently timing-sensitive and non-deterministic.

Minor observation (non-blocking): The comment references the Quarkus PR (quarkus/pull/55345) which is the downstream workaround. Consider also linking to the Quarkus issue (quarkus/issues/55317) which contains the detailed thread-dump and root-cause analysis, for future maintainer context.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.