[
https://issues.apache.org/jira/browse/CAMEL-24667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torsten Mielke updated CAMEL-24667:
-----------------------------------
Description:
*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}}
was:
*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}}
> 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)
