Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: bf41bb1b456d84aadf697b6b3f754a79e7c12817 https://github.com/xwiki/xwiki-platform/commit/bf41bb1b456d84aadf697b6b3f754... Author: Vincent Massol <vincent@massol.net> Date: 2026-07-28 (Tue, 28 Jul 2026) Changed paths: M xwiki-platform-core/xwiki-platform-repository/xwiki-platform-repository-server-api/src/main/java/org/xwiki/repository/internal/resources/ExtensionVersionFileRESTResource.java Log Message: ----------- [SONAR] Fix resource leak: migrate DefaultHttpClient to CloseableHttpClient in ExtensionVersionFileRESTResource (#5490) * [SONAR] Fix resource leak: migrate from deprecated DefaultHttpClient to CloseableHttpClient Fixes SonarCloud blocker issue S2095 in ExtensionVersionFileRESTResource.java. The DefaultHttpClient was never closed after use, leaking HTTP connections. Migrated to Apache HttpClient 5.x (already declared as direct dependency) using CloseableHttpClient with try-with-resources via response handler pattern. Also buffers the response entity as byte[] before closing the client to avoid reading from a closed connection. https://sonarcloud.io/project/issues?id=org.xwiki.platform:xwiki-platform&is... * [SONAR] Replace mutable-array lambda workaround with a local record Use a local record HttpResult instead of int[] and String[] arrays to pass data out of the response handler lambda. https://sonarcloud.io/project/issues?id=org.xwiki.platform:xwiki-platform&is... * [SONAR] Stream HTTP response back to caller instead of buffering it in memory The previous version of this fix used EntityUtils.toByteArray to buffer the entire extension content in memory before sending it to JAX-RS. This was a memory regression compared to the original streaming behavior: large extensions or many parallel downloads could cause OOM. Restore streaming by: - Using executeOpen() to get the ClassicHttpResponse without using the response handler pattern (which doesn't fit streaming). - Wrapping the entity InputStream in a FilterInputStream whose close() transitively closes the HTTP response and the HTTP client. JAX-RS calls close() on the entity stream after writing the response, so resources are released the same way the original code intended (it just never closed the client at all). - Releasing the response and client in a finally block if the handoff to JAX-RS fails before the stream is set on the response. https://sonarcloud.io/project/issues?id=org.xwiki.platform:xwiki-platform&is... * Simplify HTTP stream cleanup with Commons IO Agent-Logs-Url: https://github.com/xwiki/xwiki-platform/sessions/765e0093-1f16-4642-b66f-438... Co-authored-by: michitux <198317+michitux@users.noreply.github.com> * [SONAR] Use system HTTP client properties and stream via StreamingOutput Build the HTTP client with useSystemProperties() so it honors the JVM proxy settings, removing the explicit SystemDefaultRoutePlanner wiring. The custom User-Agent is kept because some upstream servers reject requests without one. Replace the custom ProxyInputStream subclass with a StreamingOutput that uses HttpEntity.writeTo() and closes the client and response through try-with-resources. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * [SONAR] Remove the final keyword on local variables Local variables are effectively final here, which is what the try-with-resources statement and the lambda capture require, so the explicit keyword adds nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: michitux <198317+michitux@users.noreply.github.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications