dependabot[bot] opened a new pull request, #20276: URL: https://github.com/apache/druid/pull/20276
Bumps `fabric8.version` from 7.8.0 to 7.9.0. Updates `io.fabric8:kubernetes-model-core` from 7.8.0 to 7.9.0 Updates `io.fabric8:kubernetes-model-batch` from 7.8.0 to 7.9.0 Updates `io.fabric8:kubernetes-client-api` from 7.8.0 to 7.9.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/fabric8io/kubernetes-client/releases";>io.fabric8:kubernetes-client-api's releases</a>.</em></p> <blockquote> <h2>7.9.0 (2026-09-04)</h2> <h4>Bugs</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8024";>#8024</a>: (httpclient-vertx-5) WebSocket operations (<code>exec</code>/<code>attach</code>/<code>portForward</code>/WebSocket-backed watches) on a <em>derived</em> client - one produced by calling <code>newBuilder()</code>/<code>build()</code> on an already-built <code>HttpClient</code> - no longer fall back to Vert.x's bare <code>WebSocketClient</code> defaults. <code>Vertx5HttpClientBuilder.build()</code>'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new <code>WebSocketClient</code> with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (<code>maxFrameSize</code>/<code>maxMessageSize</code> fell back to 64 KiB/256 KiB instead of unlimited, and <code>maxConnections</co de> to 50 instead of 8192, so oversized <code>exec</code>/<code>attach</code> messages were silently dropped even on plain HTTP). This affects <code>kubernetes-httpclient-vertx-5</code> only, which is opt-in - the bundled default <code>kubernetes-httpclient-vertx</code> (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: <code>OpenShiftClientImpl</code> derives on every <code>adapt(OpenShiftClient.class)</code> to install its OAuth token-refresh interceptor, <code>OpenShiftOAuthInterceptor</code> derives on every token refresh, and <code>BaseClient#newClient</code> derives whenever a differing <code>RequestConfig</code> is set. Derived clients now reuse the original's <code>WebSocketClient</code> outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note tha t sharing the transport also means closing any client in a derived family closes it for the whole family: <code>close()</code> on a client obtained from <code>adapt(OpenShiftClient.class)</code> now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation <code>WebSocketClient</code> is no longer left behind unclosed</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8029";>#8029</a>: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so <code>exec</code>/<code>attach</code>/<code>portForward</code> and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 <code>WebSocketClient</code>, and a second Jetty <code>HttpClient</code> behind the <code>WebSocketClient</code>) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy <code>BasicAuthentication</code> entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On <code>httpclient-vertx-5</code> the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth c alling out: when the proxy credentials cannot be decoded - <code>HttpClientUtils.decodeBasicCredentials</code> returns <code>null</code> for anything that is not <code>Basic</code>, or whose decoded value does not split into exactly two <code>:</code>-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping <code>Proxy-Authorization</code> on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7807";>#7807</a>: (kube-api-test) The <code>KUBE_API_TEST_STARTUP_TIMEOUT</code> environment variable is now parsed instead of throwing <code>ClassCastException</code> on every use — the value (always a <code>String</code>) was passed to <code>Class.cast()</code> for an <code>Integer</code>/<code>Boolean</code> target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new <code>startupTimeout</code> attribute on <code>@EnableKubeAPIServer</code> (e.g. <code>@EnableKubeAPIServer(startupTimeout = 180000)</code>) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7983";>#7983</a>: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous <code>HttpServerRequest#body()</code> callback. Deferring the upgrade let the request end event be processed first, so <code>HttpServerRequest#toWebSocket()</code> intermittently threw <code>IllegalStateException: Request has already been read</code> and the upgrade was lost (surfacing as flaky <code>exec</code>/<code>attach</code> mock-server tests). Upgrade requests carry no body, so they are detected via the <code>Upgrade</code> header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7955";>#7955</a>: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once <code>javac</code> decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match <code>javac</code>), aborting generation on any residual structural mismatch</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. <code>openshift-model</code> no longer bundles the <code>io.fabric8.openshift.api.model.config.*</code> classes that <code>openshift-model-config</code> owns (its <code>Export-Package</code> wildcard inlined them from that dependency); they still reach consumers through it. <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code></li> </ul> <h4>Improvements</h4> <h4>Dependency Upgrade</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: bump gateway-api from 1.5.1 to 1.6.1</li> </ul> <h4>New Features</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Support for Kubernetes v1.37.0 (Garhwal)</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model gains <code>v1.TCPRoute</code> and <code>v1.UDPRoute</code> (both graduated from <code>v1alpha2</code> upstream in gateway-api v1.6.0). The <code>v1alpha2</code> types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the <code>v1</code> types</li> </ul> <h4><em><strong>Note</strong></em>: Breaking changes</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client: <ul> <li><code>certificates.k8s.io/v1alpha1/ClusterTrustBundle</code> → use <code>certificates.k8s.io/v1</code> or <code>v1beta1</code></li> <li><code>networking.k8s.io/v1beta1/IPAddress</code> → use <code>networking.k8s.io/v1</code></li> <li><code>networking.k8s.io/v1beta1/ServiceCIDR</code> → use <code>networking.k8s.io/v1</code></li> <li><code>storage.k8s.io/v1beta1/VolumeAttributesClass</code> → use <code>storage.k8s.io/v1</code></li> <li><code>scheduling.k8s.io/v1alpha2</code> (entire API version, 28 types) → use <code>v1alpha3</code> or <code>v1beta1</code></li> </ul> </li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: <code>VolumeMount</code> constructor signature changed (Kubernetes v1.37.0 added <code>bindMountOptions</code> field). The canonical constructor now takes <code>bindMountOptions</code> (List<!-- raw HTML omitted -->) as its first parameter. Builder usage (<code>new VolumeMountBuilder().with...()</code>) is unaffected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model <code>v1.SessionPersistence</code> no longer exposes <code>idleTimeout</code> (removed upstream in gateway-api v1.6.0). Besides the field, this removes <code>getIdleTimeout()</code>/<code>setIdleTimeout()</code>, collapses the canonical constructor from five arguments to four, and drops <code>SessionPersistenceFluent.withIdleTimeout()</code>/<code>getIdleTimeout()</code>/<code>hasIdleTimeout()</code>, so the builder form (<code>withNewSessionPersistence().withIdleTimeout(...)</code>) no longer compiles. There is no runtime data loss: the class keeps its <code>@JsonAnyGetter</code>/<code>@JsonAnySetter</code>, and both the fluent and the builder carry <code>additionalProperties</code> through, so JSON or YAML still containing <code>idleTimeout</code> continues to deserialize and re-serialize intact</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (kube-api-test) <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code>. It is resolved through <code>ServiceLoader</code>, so only code naming the class directly is affected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model) The bundle no longer exports or contains <code>io.fabric8.openshift.api.model.config.*</code>. Maven consumers are unaffected (<code>openshift-model-config</code> is a compile dependency), but OSGi deployments importing those packages must install the <code>openshift-model-config</code> bundle, which the <code>openshift-client</code> Karaf feature already does</li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/mfredenhagen";><code>@mfredenhagen</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/7983";>fabric8io/kubernetes-client#7983</a></li> <li><a href="https://github.com/austek";><code>@austek</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8028";>fabric8io/kubernetes-client#8028</a></li> <li><a href="https://github.com/xstefank";><code>@xstefank</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8025";>fabric8io/kubernetes-client#8025</a></li> <li><a href="https://github.com/williamhaw";><code>@williamhaw</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8033";>fabric8io/kubernetes-client#8033</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/fabric8io/kubernetes-client/compare/v7.8.0...v7.9.0";>https://github.com/fabric8io/kubernetes-client/compare/v7.8.0...v7.9.0</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/fabric8io/kubernetes-client/blob/main/CHANGELOG.md";>io.fabric8:kubernetes-client-api's changelog</a>.</em></p> <blockquote> <h3>7.9.0 (2026-09-04)</h3> <h4>Bugs</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8024";>#8024</a>: (httpclient-vertx-5) WebSocket operations (<code>exec</code>/<code>attach</code>/<code>portForward</code>/WebSocket-backed watches) on a <em>derived</em> client - one produced by calling <code>newBuilder()</code>/<code>build()</code> on an already-built <code>HttpClient</code> - no longer fall back to Vert.x's bare <code>WebSocketClient</code> defaults. <code>Vertx5HttpClientBuilder.build()</code>'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new <code>WebSocketClient</code> with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (<code>maxFrameSize</code>/<code>maxMessageSize</code> fell back to 64 KiB/256 KiB instead of unlimited, and <code>maxConnections</co de> to 50 instead of 8192, so oversized <code>exec</code>/<code>attach</code> messages were silently dropped even on plain HTTP). This affects <code>kubernetes-httpclient-vertx-5</code> only, which is opt-in - the bundled default <code>kubernetes-httpclient-vertx</code> (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: <code>OpenShiftClientImpl</code> derives on every <code>adapt(OpenShiftClient.class)</code> to install its OAuth token-refresh interceptor, <code>OpenShiftOAuthInterceptor</code> derives on every token refresh, and <code>BaseClient#newClient</code> derives whenever a differing <code>RequestConfig</code> is set. Derived clients now reuse the original's <code>WebSocketClient</code> outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note tha t sharing the transport also means closing any client in a derived family closes it for the whole family: <code>close()</code> on a client obtained from <code>adapt(OpenShiftClient.class)</code> now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation <code>WebSocketClient</code> is no longer left behind unclosed</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8029";>#8029</a>: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so <code>exec</code>/<code>attach</code>/<code>portForward</code> and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 <code>WebSocketClient</code>, and a second Jetty <code>HttpClient</code> behind the <code>WebSocketClient</code>) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy <code>BasicAuthentication</code> entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On <code>httpclient-vertx-5</code> the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth c alling out: when the proxy credentials cannot be decoded - <code>HttpClientUtils.decodeBasicCredentials</code> returns <code>null</code> for anything that is not <code>Basic</code>, or whose decoded value does not split into exactly two <code>:</code>-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping <code>Proxy-Authorization</code> on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7807";>#7807</a>: (kube-api-test) The <code>KUBE_API_TEST_STARTUP_TIMEOUT</code> environment variable is now parsed instead of throwing <code>ClassCastException</code> on every use — the value (always a <code>String</code>) was passed to <code>Class.cast()</code> for an <code>Integer</code>/<code>Boolean</code> target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new <code>startupTimeout</code> attribute on <code>@EnableKubeAPIServer</code> (e.g. <code>@EnableKubeAPIServer(startupTimeout = 180000)</code>) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7983";>#7983</a>: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous <code>HttpServerRequest#body()</code> callback. Deferring the upgrade let the request end event be processed first, so <code>HttpServerRequest#toWebSocket()</code> intermittently threw <code>IllegalStateException: Request has already been read</code> and the upgrade was lost (surfacing as flaky <code>exec</code>/<code>attach</code> mock-server tests). Upgrade requests carry no body, so they are detected via the <code>Upgrade</code> header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7955";>#7955</a>: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once <code>javac</code> decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match <code>javac</code>), aborting generation on any residual structural mismatch</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. <code>openshift-model</code> no longer bundles the <code>io.fabric8.openshift.api.model.config.*</code> classes that <code>openshift-model-config</code> owns (its <code>Export-Package</code> wildcard inlined them from that dependency); they still reach consumers through it. <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code></li> </ul> <h4>Improvements</h4> <h4>Dependency Upgrade</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: bump gateway-api from 1.5.1 to 1.6.1</li> </ul> <h4>New Features</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Support for Kubernetes v1.37.0 (Garhwal)</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model gains <code>v1.TCPRoute</code> and <code>v1.UDPRoute</code> (both graduated from <code>v1alpha2</code> upstream in gateway-api v1.6.0). The <code>v1alpha2</code> types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the <code>v1</code> types</li> </ul> <h4><em><strong>Note</strong></em>: Breaking changes</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client: <ul> <li><code>certificates.k8s.io/v1alpha1/ClusterTrustBundle</code> → use <code>certificates.k8s.io/v1</code> or <code>v1beta1</code></li> <li><code>networking.k8s.io/v1beta1/IPAddress</code> → use <code>networking.k8s.io/v1</code></li> <li><code>networking.k8s.io/v1beta1/ServiceCIDR</code> → use <code>networking.k8s.io/v1</code></li> <li><code>storage.k8s.io/v1beta1/VolumeAttributesClass</code> → use <code>storage.k8s.io/v1</code></li> <li><code>scheduling.k8s.io/v1alpha2</code> (entire API version, 28 types) → use <code>v1alpha3</code> or <code>v1beta1</code></li> </ul> </li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: <code>VolumeMount</code> constructor signature changed (Kubernetes v1.37.0 added <code>bindMountOptions</code> field). The canonical constructor now takes <code>bindMountOptions</code> (List<!-- raw HTML omitted -->) as its first parameter. Builder usage (<code>new VolumeMountBuilder().with...()</code>) is unaffected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model <code>v1.SessionPersistence</code> no longer exposes <code>idleTimeout</code> (removed upstream in gateway-api v1.6.0). Besides the field, this removes <code>getIdleTimeout()</code>/<code>setIdleTimeout()</code>, collapses the canonical constructor from five arguments to four, and drops <code>SessionPersistenceFluent.withIdleTimeout()</code>/<code>getIdleTimeout()</code>/<code>hasIdleTimeout()</code>, so the builder form (<code>withNewSessionPersistence().withIdleTimeout(...)</code>) no longer compiles. There is no runtime data loss: the class keeps its <code>@JsonAnyGetter</code>/<code>@JsonAnySetter</code>, and both the fluent and the builder carry <code>additionalProperties</code> through, so JSON or YAML still containing <code>idleTimeout</code> continues to deserialize and re-serialize intact</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (kube-api-test) <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code>. It is resolved through <code>ServiceLoader</code>, so only code naming the class directly is affected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model) The bundle no longer exports or contains <code>io.fabric8.openshift.api.model.config.*</code>. Maven consumers are unaffected (<code>openshift-model-config</code> is a compile dependency), but OSGi deployments importing those packages must install the <code>openshift-model-config</code> bundle, which the <code>openshift-client</code> Karaf feature already does</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/c6d4ff33a446f6757e778ea0421830976089e180";><code>c6d4ff3</code></a> [RELEASE] Updated project version to v7.9.0</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/feced2afdee20a89da2167ac2626ab566b5e7ff3";><code>feced2a</code></a> feat(openapi): support for Kubernetes v1.37 (Garhwal) (<a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>)</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/45be75ff156a56e07fa62fb1822233c0f697f449";><code>45be75f</code></a> chore(deps): bump actions/setup-java in the github-actions group</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/8ba02fc72d4b51d8836fbda245733851fa009463";><code>8ba02fc</code></a> chore(deps): tidy go.sum and expand gateway-api changelog (8033)</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/687d91e139b628566b6b8a13548dc854c7599a09";><code>687d91e</code></a> chore(deps): bump gateway-api from 1.5.1 to 1.6.1</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/ceb92181015d766d7ab7f107da5a47b40d7a991f";><code>ceb9218</code></a> fix(httpclient): WebSocket transport reuse on derived clients and proxy suppo...</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/c641839f404969a57e370813a75f808f354cbd42";><code>c641839</code></a> fix(httpclient-vertx-5): trust configured certificate for WebSocket on derive...</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/a2864e1f774638e674c7e080f3b8fdf58767aed5";><code>a2864e1</code></a> fix: eliminate split packages in openshift-model and kube-api-test (7986) (8028)</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/10b8f98d1c88c3612f7cd753230faa1b19e4db78";><code>10b8f98</code></a> chore(deps): bump org.apache.groovy:groovy-all from 5.0.7 to 5.0.8</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/91e8b76de07a6d2a66524f6b1cb36ce53f525cc7";><code>91e8b76</code></a> chore(deps): bump io.swagger.parser.v3:swagger-parser</li> <li>Additional commits viewable in <a href="https://github.com/fabric8io/kubernetes-client/compare/v7.8.0...v7.9.0";>compare view</a></li> </ul> </details> <br /> Updates `io.fabric8:kubernetes-client` from 7.8.0 to 7.9.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/fabric8io/kubernetes-client/releases";>io.fabric8:kubernetes-client's releases</a>.</em></p> <blockquote> <h2>7.9.0 (2026-09-04)</h2> <h4>Bugs</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8024";>#8024</a>: (httpclient-vertx-5) WebSocket operations (<code>exec</code>/<code>attach</code>/<code>portForward</code>/WebSocket-backed watches) on a <em>derived</em> client - one produced by calling <code>newBuilder()</code>/<code>build()</code> on an already-built <code>HttpClient</code> - no longer fall back to Vert.x's bare <code>WebSocketClient</code> defaults. <code>Vertx5HttpClientBuilder.build()</code>'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new <code>WebSocketClient</code> with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (<code>maxFrameSize</code>/<code>maxMessageSize</code> fell back to 64 KiB/256 KiB instead of unlimited, and <code>maxConnections</co de> to 50 instead of 8192, so oversized <code>exec</code>/<code>attach</code> messages were silently dropped even on plain HTTP). This affects <code>kubernetes-httpclient-vertx-5</code> only, which is opt-in - the bundled default <code>kubernetes-httpclient-vertx</code> (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: <code>OpenShiftClientImpl</code> derives on every <code>adapt(OpenShiftClient.class)</code> to install its OAuth token-refresh interceptor, <code>OpenShiftOAuthInterceptor</code> derives on every token refresh, and <code>BaseClient#newClient</code> derives whenever a differing <code>RequestConfig</code> is set. Derived clients now reuse the original's <code>WebSocketClient</code> outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note tha t sharing the transport also means closing any client in a derived family closes it for the whole family: <code>close()</code> on a client obtained from <code>adapt(OpenShiftClient.class)</code> now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation <code>WebSocketClient</code> is no longer left behind unclosed</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8029";>#8029</a>: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so <code>exec</code>/<code>attach</code>/<code>portForward</code> and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 <code>WebSocketClient</code>, and a second Jetty <code>HttpClient</code> behind the <code>WebSocketClient</code>) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy <code>BasicAuthentication</code> entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On <code>httpclient-vertx-5</code> the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth c alling out: when the proxy credentials cannot be decoded - <code>HttpClientUtils.decodeBasicCredentials</code> returns <code>null</code> for anything that is not <code>Basic</code>, or whose decoded value does not split into exactly two <code>:</code>-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping <code>Proxy-Authorization</code> on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7807";>#7807</a>: (kube-api-test) The <code>KUBE_API_TEST_STARTUP_TIMEOUT</code> environment variable is now parsed instead of throwing <code>ClassCastException</code> on every use — the value (always a <code>String</code>) was passed to <code>Class.cast()</code> for an <code>Integer</code>/<code>Boolean</code> target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new <code>startupTimeout</code> attribute on <code>@EnableKubeAPIServer</code> (e.g. <code>@EnableKubeAPIServer(startupTimeout = 180000)</code>) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7983";>#7983</a>: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous <code>HttpServerRequest#body()</code> callback. Deferring the upgrade let the request end event be processed first, so <code>HttpServerRequest#toWebSocket()</code> intermittently threw <code>IllegalStateException: Request has already been read</code> and the upgrade was lost (surfacing as flaky <code>exec</code>/<code>attach</code> mock-server tests). Upgrade requests carry no body, so they are detected via the <code>Upgrade</code> header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7955";>#7955</a>: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once <code>javac</code> decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match <code>javac</code>), aborting generation on any residual structural mismatch</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. <code>openshift-model</code> no longer bundles the <code>io.fabric8.openshift.api.model.config.*</code> classes that <code>openshift-model-config</code> owns (its <code>Export-Package</code> wildcard inlined them from that dependency); they still reach consumers through it. <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code></li> </ul> <h4>Improvements</h4> <h4>Dependency Upgrade</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: bump gateway-api from 1.5.1 to 1.6.1</li> </ul> <h4>New Features</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Support for Kubernetes v1.37.0 (Garhwal)</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model gains <code>v1.TCPRoute</code> and <code>v1.UDPRoute</code> (both graduated from <code>v1alpha2</code> upstream in gateway-api v1.6.0). The <code>v1alpha2</code> types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the <code>v1</code> types</li> </ul> <h4><em><strong>Note</strong></em>: Breaking changes</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client: <ul> <li><code>certificates.k8s.io/v1alpha1/ClusterTrustBundle</code> → use <code>certificates.k8s.io/v1</code> or <code>v1beta1</code></li> <li><code>networking.k8s.io/v1beta1/IPAddress</code> → use <code>networking.k8s.io/v1</code></li> <li><code>networking.k8s.io/v1beta1/ServiceCIDR</code> → use <code>networking.k8s.io/v1</code></li> <li><code>storage.k8s.io/v1beta1/VolumeAttributesClass</code> → use <code>storage.k8s.io/v1</code></li> <li><code>scheduling.k8s.io/v1alpha2</code> (entire API version, 28 types) → use <code>v1alpha3</code> or <code>v1beta1</code></li> </ul> </li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: <code>VolumeMount</code> constructor signature changed (Kubernetes v1.37.0 added <code>bindMountOptions</code> field). The canonical constructor now takes <code>bindMountOptions</code> (List<!-- raw HTML omitted -->) as its first parameter. Builder usage (<code>new VolumeMountBuilder().with...()</code>) is unaffected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model <code>v1.SessionPersistence</code> no longer exposes <code>idleTimeout</code> (removed upstream in gateway-api v1.6.0). Besides the field, this removes <code>getIdleTimeout()</code>/<code>setIdleTimeout()</code>, collapses the canonical constructor from five arguments to four, and drops <code>SessionPersistenceFluent.withIdleTimeout()</code>/<code>getIdleTimeout()</code>/<code>hasIdleTimeout()</code>, so the builder form (<code>withNewSessionPersistence().withIdleTimeout(...)</code>) no longer compiles. There is no runtime data loss: the class keeps its <code>@JsonAnyGetter</code>/<code>@JsonAnySetter</code>, and both the fluent and the builder carry <code>additionalProperties</code> through, so JSON or YAML still containing <code>idleTimeout</code> continues to deserialize and re-serialize intact</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (kube-api-test) <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code>. It is resolved through <code>ServiceLoader</code>, so only code naming the class directly is affected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model) The bundle no longer exports or contains <code>io.fabric8.openshift.api.model.config.*</code>. Maven consumers are unaffected (<code>openshift-model-config</code> is a compile dependency), but OSGi deployments importing those packages must install the <code>openshift-model-config</code> bundle, which the <code>openshift-client</code> Karaf feature already does</li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/mfredenhagen";><code>@mfredenhagen</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/7983";>fabric8io/kubernetes-client#7983</a></li> <li><a href="https://github.com/austek";><code>@austek</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8028";>fabric8io/kubernetes-client#8028</a></li> <li><a href="https://github.com/xstefank";><code>@xstefank</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8025";>fabric8io/kubernetes-client#8025</a></li> <li><a href="https://github.com/williamhaw";><code>@williamhaw</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8033";>fabric8io/kubernetes-client#8033</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/fabric8io/kubernetes-client/compare/v7.8.0...v7.9.0";>https://github.com/fabric8io/kubernetes-client/compare/v7.8.0...v7.9.0</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/fabric8io/kubernetes-client/blob/main/CHANGELOG.md";>io.fabric8:kubernetes-client's changelog</a>.</em></p> <blockquote> <h3>7.9.0 (2026-09-04)</h3> <h4>Bugs</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8024";>#8024</a>: (httpclient-vertx-5) WebSocket operations (<code>exec</code>/<code>attach</code>/<code>portForward</code>/WebSocket-backed watches) on a <em>derived</em> client - one produced by calling <code>newBuilder()</code>/<code>build()</code> on an already-built <code>HttpClient</code> - no longer fall back to Vert.x's bare <code>WebSocketClient</code> defaults. <code>Vertx5HttpClientBuilder.build()</code>'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new <code>WebSocketClient</code> with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (<code>maxFrameSize</code>/<code>maxMessageSize</code> fell back to 64 KiB/256 KiB instead of unlimited, and <code>maxConnections</co de> to 50 instead of 8192, so oversized <code>exec</code>/<code>attach</code> messages were silently dropped even on plain HTTP). This affects <code>kubernetes-httpclient-vertx-5</code> only, which is opt-in - the bundled default <code>kubernetes-httpclient-vertx</code> (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: <code>OpenShiftClientImpl</code> derives on every <code>adapt(OpenShiftClient.class)</code> to install its OAuth token-refresh interceptor, <code>OpenShiftOAuthInterceptor</code> derives on every token refresh, and <code>BaseClient#newClient</code> derives whenever a differing <code>RequestConfig</code> is set. Derived clients now reuse the original's <code>WebSocketClient</code> outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note tha t sharing the transport also means closing any client in a derived family closes it for the whole family: <code>close()</code> on a client obtained from <code>adapt(OpenShiftClient.class)</code> now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation <code>WebSocketClient</code> is no longer left behind unclosed</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8029";>#8029</a>: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so <code>exec</code>/<code>attach</code>/<code>portForward</code> and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 <code>WebSocketClient</code>, and a second Jetty <code>HttpClient</code> behind the <code>WebSocketClient</code>) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy <code>BasicAuthentication</code> entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On <code>httpclient-vertx-5</code> the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth c alling out: when the proxy credentials cannot be decoded - <code>HttpClientUtils.decodeBasicCredentials</code> returns <code>null</code> for anything that is not <code>Basic</code>, or whose decoded value does not split into exactly two <code>:</code>-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping <code>Proxy-Authorization</code> on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7807";>#7807</a>: (kube-api-test) The <code>KUBE_API_TEST_STARTUP_TIMEOUT</code> environment variable is now parsed instead of throwing <code>ClassCastException</code> on every use — the value (always a <code>String</code>) was passed to <code>Class.cast()</code> for an <code>Integer</code>/<code>Boolean</code> target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new <code>startupTimeout</code> attribute on <code>@EnableKubeAPIServer</code> (e.g. <code>@EnableKubeAPIServer(startupTimeout = 180000)</code>) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7983";>#7983</a>: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous <code>HttpServerRequest#body()</code> callback. Deferring the upgrade let the request end event be processed first, so <code>HttpServerRequest#toWebSocket()</code> intermittently threw <code>IllegalStateException: Request has already been read</code> and the upgrade was lost (surfacing as flaky <code>exec</code>/<code>attach</code> mock-server tests). Upgrade requests carry no body, so they are detected via the <code>Upgrade</code> header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7955";>#7955</a>: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once <code>javac</code> decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match <code>javac</code>), aborting generation on any residual structural mismatch</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. <code>openshift-model</code> no longer bundles the <code>io.fabric8.openshift.api.model.config.*</code> classes that <code>openshift-model-config</code> owns (its <code>Export-Package</code> wildcard inlined them from that dependency); they still reach consumers through it. <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code></li> </ul> <h4>Improvements</h4> <h4>Dependency Upgrade</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: bump gateway-api from 1.5.1 to 1.6.1</li> </ul> <h4>New Features</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Support for Kubernetes v1.37.0 (Garhwal)</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model gains <code>v1.TCPRoute</code> and <code>v1.UDPRoute</code> (both graduated from <code>v1alpha2</code> upstream in gateway-api v1.6.0). The <code>v1alpha2</code> types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the <code>v1</code> types</li> </ul> <h4><em><strong>Note</strong></em>: Breaking changes</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client: <ul> <li><code>certificates.k8s.io/v1alpha1/ClusterTrustBundle</code> → use <code>certificates.k8s.io/v1</code> or <code>v1beta1</code></li> <li><code>networking.k8s.io/v1beta1/IPAddress</code> → use <code>networking.k8s.io/v1</code></li> <li><code>networking.k8s.io/v1beta1/ServiceCIDR</code> → use <code>networking.k8s.io/v1</code></li> <li><code>storage.k8s.io/v1beta1/VolumeAttributesClass</code> → use <code>storage.k8s.io/v1</code></li> <li><code>scheduling.k8s.io/v1alpha2</code> (entire API version, 28 types) → use <code>v1alpha3</code> or <code>v1beta1</code></li> </ul> </li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: <code>VolumeMount</code> constructor signature changed (Kubernetes v1.37.0 added <code>bindMountOptions</code> field). The canonical constructor now takes <code>bindMountOptions</code> (List<!-- raw HTML omitted -->) as its first parameter. Builder usage (<code>new VolumeMountBuilder().with...()</code>) is unaffected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model <code>v1.SessionPersistence</code> no longer exposes <code>idleTimeout</code> (removed upstream in gateway-api v1.6.0). Besides the field, this removes <code>getIdleTimeout()</code>/<code>setIdleTimeout()</code>, collapses the canonical constructor from five arguments to four, and drops <code>SessionPersistenceFluent.withIdleTimeout()</code>/<code>getIdleTimeout()</code>/<code>hasIdleTimeout()</code>, so the builder form (<code>withNewSessionPersistence().withIdleTimeout(...)</code>) no longer compiles. There is no runtime data loss: the class keeps its <code>@JsonAnyGetter</code>/<code>@JsonAnySetter</code>, and both the fluent and the builder carry <code>additionalProperties</code> through, so JSON or YAML still containing <code>idleTimeout</code> continues to deserialize and re-serialize intact</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (kube-api-test) <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code>. It is resolved through <code>ServiceLoader</code>, so only code naming the class directly is affected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model) The bundle no longer exports or contains <code>io.fabric8.openshift.api.model.config.*</code>. Maven consumers are unaffected (<code>openshift-model-config</code> is a compile dependency), but OSGi deployments importing those packages must install the <code>openshift-model-config</code> bundle, which the <code>openshift-client</code> Karaf feature already does</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/c6d4ff33a446f6757e778ea0421830976089e180";><code>c6d4ff3</code></a> [RELEASE] Updated project version to v7.9.0</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/feced2afdee20a89da2167ac2626ab566b5e7ff3";><code>feced2a</code></a> feat(openapi): support for Kubernetes v1.37 (Garhwal) (<a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>)</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/45be75ff156a56e07fa62fb1822233c0f697f449";><code>45be75f</code></a> chore(deps): bump actions/setup-java in the github-actions group</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/8ba02fc72d4b51d8836fbda245733851fa009463";><code>8ba02fc</code></a> chore(deps): tidy go.sum and expand gateway-api changelog (8033)</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/687d91e139b628566b6b8a13548dc854c7599a09";><code>687d91e</code></a> chore(deps): bump gateway-api from 1.5.1 to 1.6.1</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/ceb92181015d766d7ab7f107da5a47b40d7a991f";><code>ceb9218</code></a> fix(httpclient): WebSocket transport reuse on derived clients and proxy suppo...</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/c641839f404969a57e370813a75f808f354cbd42";><code>c641839</code></a> fix(httpclient-vertx-5): trust configured certificate for WebSocket on derive...</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/a2864e1f774638e674c7e080f3b8fdf58767aed5";><code>a2864e1</code></a> fix: eliminate split packages in openshift-model and kube-api-test (7986) (8028)</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/10b8f98d1c88c3612f7cd753230faa1b19e4db78";><code>10b8f98</code></a> chore(deps): bump org.apache.groovy:groovy-all from 5.0.7 to 5.0.8</li> <li><a href="https://github.com/fabric8io/kubernetes-client/commit/91e8b76de07a6d2a66524f6b1cb36ce53f525cc7";><code>91e8b76</code></a> chore(deps): bump io.swagger.parser.v3:swagger-parser</li> <li>Additional commits viewable in <a href="https://github.com/fabric8io/kubernetes-client/compare/v7.8.0...v7.9.0";>compare view</a></li> </ul> </details> <br /> Updates `io.fabric8:kubernetes-httpclient-jdk` from 7.8.0 to 7.9.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/fabric8io/kubernetes-client/releases";>io.fabric8:kubernetes-httpclient-jdk's releases</a>.</em></p> <blockquote> <h2>7.9.0 (2026-09-04)</h2> <h4>Bugs</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8024";>#8024</a>: (httpclient-vertx-5) WebSocket operations (<code>exec</code>/<code>attach</code>/<code>portForward</code>/WebSocket-backed watches) on a <em>derived</em> client - one produced by calling <code>newBuilder()</code>/<code>build()</code> on an already-built <code>HttpClient</code> - no longer fall back to Vert.x's bare <code>WebSocketClient</code> defaults. <code>Vertx5HttpClientBuilder.build()</code>'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new <code>WebSocketClient</code> with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (<code>maxFrameSize</code>/<code>maxMessageSize</code> fell back to 64 KiB/256 KiB instead of unlimited, and <code>maxConnections</co de> to 50 instead of 8192, so oversized <code>exec</code>/<code>attach</code> messages were silently dropped even on plain HTTP). This affects <code>kubernetes-httpclient-vertx-5</code> only, which is opt-in - the bundled default <code>kubernetes-httpclient-vertx</code> (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: <code>OpenShiftClientImpl</code> derives on every <code>adapt(OpenShiftClient.class)</code> to install its OAuth token-refresh interceptor, <code>OpenShiftOAuthInterceptor</code> derives on every token refresh, and <code>BaseClient#newClient</code> derives whenever a differing <code>RequestConfig</code> is set. Derived clients now reuse the original's <code>WebSocketClient</code> outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note tha t sharing the transport also means closing any client in a derived family closes it for the whole family: <code>close()</code> on a client obtained from <code>adapt(OpenShiftClient.class)</code> now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation <code>WebSocketClient</code> is no longer left behind unclosed</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8029";>#8029</a>: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so <code>exec</code>/<code>attach</code>/<code>portForward</code> and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 <code>WebSocketClient</code>, and a second Jetty <code>HttpClient</code> behind the <code>WebSocketClient</code>) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy <code>BasicAuthentication</code> entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On <code>httpclient-vertx-5</code> the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth c alling out: when the proxy credentials cannot be decoded - <code>HttpClientUtils.decodeBasicCredentials</code> returns <code>null</code> for anything that is not <code>Basic</code>, or whose decoded value does not split into exactly two <code>:</code>-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping <code>Proxy-Authorization</code> on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7807";>#7807</a>: (kube-api-test) The <code>KUBE_API_TEST_STARTUP_TIMEOUT</code> environment variable is now parsed instead of throwing <code>ClassCastException</code> on every use — the value (always a <code>String</code>) was passed to <code>Class.cast()</code> for an <code>Integer</code>/<code>Boolean</code> target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new <code>startupTimeout</code> attribute on <code>@EnableKubeAPIServer</code> (e.g. <code>@EnableKubeAPIServer(startupTimeout = 180000)</code>) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7983";>#7983</a>: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous <code>HttpServerRequest#body()</code> callback. Deferring the upgrade let the request end event be processed first, so <code>HttpServerRequest#toWebSocket()</code> intermittently threw <code>IllegalStateException: Request has already been read</code> and the upgrade was lost (surfacing as flaky <code>exec</code>/<code>attach</code> mock-server tests). Upgrade requests carry no body, so they are detected via the <code>Upgrade</code> header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7955";>#7955</a>: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once <code>javac</code> decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match <code>javac</code>), aborting generation on any residual structural mismatch</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. <code>openshift-model</code> no longer bundles the <code>io.fabric8.openshift.api.model.config.*</code> classes that <code>openshift-model-config</code> owns (its <code>Export-Package</code> wildcard inlined them from that dependency); they still reach consumers through it. <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code></li> </ul> <h4>Improvements</h4> <h4>Dependency Upgrade</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: bump gateway-api from 1.5.1 to 1.6.1</li> </ul> <h4>New Features</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Support for Kubernetes v1.37.0 (Garhwal)</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model gains <code>v1.TCPRoute</code> and <code>v1.UDPRoute</code> (both graduated from <code>v1alpha2</code> upstream in gateway-api v1.6.0). The <code>v1alpha2</code> types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the <code>v1</code> types</li> </ul> <h4><em><strong>Note</strong></em>: Breaking changes</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client: <ul> <li><code>certificates.k8s.io/v1alpha1/ClusterTrustBundle</code> → use <code>certificates.k8s.io/v1</code> or <code>v1beta1</code></li> <li><code>networking.k8s.io/v1beta1/IPAddress</code> → use <code>networking.k8s.io/v1</code></li> <li><code>networking.k8s.io/v1beta1/ServiceCIDR</code> → use <code>networking.k8s.io/v1</code></li> <li><code>storage.k8s.io/v1beta1/VolumeAttributesClass</code> → use <code>storage.k8s.io/v1</code></li> <li><code>scheduling.k8s.io/v1alpha2</code> (entire API version, 28 types) → use <code>v1alpha3</code> or <code>v1beta1</code></li> </ul> </li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/7752";>#7752</a>: <code>VolumeMount</code> constructor signature changed (Kubernetes v1.37.0 added <code>bindMountOptions</code> field). The canonical constructor now takes <code>bindMountOptions</code> (List<!-- raw HTML omitted -->) as its first parameter. Builder usage (<code>new VolumeMountBuilder().with...()</code>) is unaffected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8033";>#8033</a>: gateway-api model <code>v1.SessionPersistence</code> no longer exposes <code>idleTimeout</code> (removed upstream in gateway-api v1.6.0). Besides the field, this removes <code>getIdleTimeout()</code>/<code>setIdleTimeout()</code>, collapses the canonical constructor from five arguments to four, and drops <code>SessionPersistenceFluent.withIdleTimeout()</code>/<code>getIdleTimeout()</code>/<code>hasIdleTimeout()</code>, so the builder form (<code>withNewSessionPersistence().withIdleTimeout(...)</code>) no longer compiles. There is no runtime data loss: the class keeps its <code>@JsonAnyGetter</code>/<code>@JsonAnySetter</code>, and both the fluent and the builder carry <code>additionalProperties</code> through, so JSON or YAML still containing <code>idleTimeout</code> continues to deserialize and re-serialize intact</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (kube-api-test) <code>Fabric8ClientInjectionHandler</code> moved to <code>io.fabric8.kubeapitest.junit.inject</code>. It is resolved through <code>ServiceLoader</code>, so only code naming the class directly is affected</li> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8028";>#8028</a>: (openshift-model) The bundle no longer exports or contains <code>io.fabric8.openshift.api.model.config.*</code>. Maven consumers are unaffected (<code>openshift-model-config</code> is a compile dependency), but OSGi deployments importing those packages must install the <code>openshift-model-config</code> bundle, which the <code>openshift-client</code> Karaf feature already does</li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/mfredenhagen";><code>@mfredenhagen</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/7983";>fabric8io/kubernetes-client#7983</a></li> <li><a href="https://github.com/austek";><code>@austek</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8028";>fabric8io/kubernetes-client#8028</a></li> <li><a href="https://github.com/xstefank";><code>@xstefank</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8025";>fabric8io/kubernetes-client#8025</a></li> <li><a href="https://github.com/williamhaw";><code>@williamhaw</code></a> made their first contribution in <a href="https://redirect.github.com/fabric8io/kubernetes-client/pull/8033";>fabric8io/kubernetes-client#8033</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/fabric8io/kubernetes-client/compare/v7.8.0...v7.9.0";>https://github.com/fabric8io/kubernetes-client/compare/v7.8.0...v7.9.0</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/fabric8io/kubernetes-client/blob/main/CHANGELOG.md";>io.fabric8:kubernetes-httpclient-jdk's changelog</a>.</em></p> <blockquote> <h3>7.9.0 (2026-09-04)</h3> <h4>Bugs</h4> <ul> <li>Fix <a href="https://redirect.github.com/fabric8io/kubernetes-client/issues/8024";>#8024</a>: (httpclient-vertx-5) WebSocket operations (<code>exec</code>/<code>attach</code... _Description has been truncated_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
