task: Use getInputStream to get data - #378
Conversation
As reported in #377 - getContent() when building with GraalVM uses serviceloaders to locate the correct content processor. But we've already checked that we don't have a gzip stream, so we're trusting our upstream to return application/json and do not need a content processor. This saves us a cast from content to InputStream as well. fixes: #377
Coverage Report for CI Build 26277735635Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Coverage increased (+0.3%) to 79.944%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
There was a problem hiding this comment.
Pull request overview
This PR updates the HttpFeatureFetcher to read response bodies via HttpURLConnection#getInputStream() instead of getContent(), avoiding ServiceLoader-based content handler resolution that can break under GraalVM native-image (as reported in #377). It also corrects a malformed Maven project version string in the root pom.xml.
Changes:
- Replace
(InputStream) request.getContent()withrequest.getInputStream()when reading the non-gzip JSON response body. - Fix
pom.xmlproject version from12.2.2-SNAPSHOT-SNAPSHOTto12.2.2-SNAPSHOT. - Minor XML formatting/indentation adjustment around
distributionManagementwithin thepublicationprofile.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/main/java/io/getunleash/repository/HttpFeatureFetcher.java |
Avoids getContent() content-handler resolution by reading the response via getInputStream() (more reliable under GraalVM). |
pom.xml |
Fixes malformed project version and tidies indentation near profile distribution management. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
As reported in #377 - getContent() uses serviceloaders to locate the correct content processor. With GraalVM, depending on your configuration it can locate the wrong content processor and give you bad data.
We've already checked that we don't have a gzip stream, so we're trusting our upstream to return application/json and do not need a content processor. This saves us a cast from content to InputStream as well.
fixes: #377