[
https://issues.apache.org/jira/browse/CAMEL-24667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18113879#comment-18113879
]
Torsten Mielke commented on CAMEL-24667:
----------------------------------------
Looking further ....
When exporting the route to a Camel Quarkus Maven project ({{{}camel export
--runtime=quarkus{}}}) the generated project also fails when run via {{mvn
quarkus:dev}} but succeeds when run via {{{}mvn quarkus:run{}}}.
With the help of AI we found why {{quarkus:dev}} fails but {{quarkus:run}}
succeeds:
1. *quarkus:run* launches the pre-built fast-jar from target/quarkus-app/.
The packaged app doesn't include {{quarkus-vertx-http}} or {{brotli4j}} — the
project only depends on {{camel-quarkus-http}} (which uses Apache HttpClient 5,
not Vert.x). Since brotli4j isn't on the classpath, Apache HttpClient's
{{Brotli4jRuntime.available() returns false, it doesn't advertise
Accept-Encoding: br, and everything works.
2. *quarkus:dev* runs Quarkus in development mode, which starts the Quarkus
dev infrastructure: the dev UI, live reload server, and continuous testing
framework.
This infrastructure requires {{quarkus-vertx-http}} — Quarkus's embedded HTTP
server. {{quarkus-vertx-http}} has a compile-scope dependency on the brotli4j
API jar (added for Quarkus HTTP server Brotli compression support per
quarkus#43556). In dev mode, all infrastructure dependencies are on the
classpath. Apache HttpClient 5 sees the brotli4j API class via
{{Class.forName("com.aayushatharva.brotli4j.Brotli4jLoader", false, ...)}} —
which only checks class presence, NOT native library loadability — and
advertises {{{}Accept-Encoding: br, gzip, deflate{}}}. When a server responds
with {{{}Content-Encoding: br{}}}, HttpClient tries to decompress using
Brotli4j, which triggers native library loading → {{UnsatisfiedLinkError}}
because the platform-specific JNI artifact isn't on the classpath (Maven
doesn't activate profile-based platform selection for transitive dependencies).
3. And why does {{camel run --runtime=quarkus}} also not work?
The dependency chain for camel run --runtime=quarkus:
{code:java}
camel run --runtime=quarkus
└─ always adds: camel:cli-connector (Run.java line 1531)
└─ camel-quarkus-cli-connector
└─ camel-quarkus-console
└─ quarkus-vertx-http ← pulls in brotli4j
└─ com.aayushatharva.brotli4j:brotli4j (API jar only, no
native lib)
{code}
{{camel run --runtime=quarkus}} always adds {{camel:cli-connector}} as a
dependency (it provides the connection between the running Camel app and the
camel CLI for commands like camel get, camel top, etc.). The Quarkus version of
this extension ({{{}camel-quarkus-cli-connector{}}}) depends on
{{{}camel-quarkus-console{}}}, which depends on {{quarkus-vertx-http}} — and
that's what brings brotli4j onto the classpath.
> camel-http: UnsatisfiedLinkError for Brotli4j when using Quarkus runtime
> ------------------------------------------------------------------------
>
> Key: CAMEL-24667
> URL: https://issues.apache.org/jira/browse/CAMEL-24667
> Project: Camel
> Issue Type: Bug
> Components: camel-http
> Affects Versions: 4.22.0
> Reporter: Torsten Mielke
> Assignee: Torsten Mielke
> Priority: Minor
>
> *Description*
> When running a Camel route that uses the HTTP component (`toD` with
> `https://` URI) with the Quarkus runtime (e.g. via {{{}camel run
> --runtime=quarkus{}}}), the route fails with:{{{{}}{}}}
> {code:java}
> java.lang.UnsatisfiedLinkError: 'java.nio.ByteBuffer
> com.aayushatharva.brotli4j.decoder.DecoderJNI.nativeCreate(long[])'The same
> route works fine with Camel Main and Spring Boot runtimes.{code}
> A sample route in YAML DSL would be
> {code:java}
> - route:
> from:
> uri: timer:test
> parameters:
> period: "2000"
> repeatCount: 1
> steps:
> - toD:
> uri: "https://jsonplaceholder.typicode.com/posts/1";
> parameters:
> throwExceptionOnFailure: true
> - log: ${body}{code}
>
> *Root Cause*
> The {{quarkus-vertx-http}} dependency transitively pulls in the {{brotli4j}}
> API jar. However, brotli4j uses Maven profile activation to include
> platform-specific native JNI artifacts (e.g. {{{}native-osx-aarch64{}}}), and
> Maven does not activate profiles in transitive dependency POMs. This means:
> 1. The {{brotli4j}} Java API classes are on the classpath
> 2. The platform-native JNI library (`.dylib`/`.so`) is *not* on the classpath
> 3. Apache HttpClient 5's {{Brotli4jRuntime.available()}} check passes (it
> only checks class presence via {{Class.forName}} with
> {{{}initialize=false{}}}, not JNI loadability)
> 4. HttpClient registers a Brotli content decoder and adds {{br}} to the
> {{Accept-Encoding}} request header
> 5. The server responds with Brotli-compressed content
> 6. Decompression fails with {{UnsatisfiedLinkError}} because the native
> library was never loaded
> With Camel Main and Spring Boot, brotli4j is declared optional in httpclient5
> and nothing else pulls it in, so the Brotli decoder is never registered and
> the issue does not occur.
> *Workaround*
> Disable compression in `application.properties`:
> {{camel.component.http.contentCompressionDisabled=true}}
> {{camel.component.https.contentCompressionDisabled=true}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
