jamesnetherton commented on issue #9110:
URL: https://github.com/apache/camel-quarkus/issues/9110#issuecomment-5568928327
I checked the quoted claim against Quarkus 3.39.2 (the version currently in
our root `pom.xml`). It is partly accurate, but the conclusion that the build
item is a no-op is wrong.
### Accurate part
`NativeImageConfigBuildStep.build()` does unconditionally enable SSL at
runtime:
```java
//
core/deployment/src/main/java/io/quarkus/deployment/steps/NativeImageConfigBuildStep.java#L58-L60
// For now, we enable SSL native if it hasn't been explicitly disabled
// it's probably overly conservative but it's a first step in the right
direction
sslContextConfigurationRecorder.setSslNativeEnabled(!sslNativeConfig.isExplicitlyDisabled());
```
So `SslContextConfiguration.isSslNativeEnabled()` — which
`Target_javax_net_ssl_SSLContext.getDefault()` uses to choose between a real
`SSLContext` and `DisabledSSLContext` — does not depend on
`ExtensionSslNativeSupportBuildItem`.
### Where the claim breaks down
The `quarkus.ssl.native` value produced on line 63 is not "a secondary
native image system property". `NativeImageBuildStep` intercepts that key
instead of passing it through as `-J-D`:
```java
//
core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildStep.java
if (prop.getKey().equals("quarkus.ssl.native") && prop.getValue() != null) {
// L842
enableSslNative = Boolean.parseBoolean(prop.getValue());
}
...
if (enableSslNative) {
// L870
enableHttpsUrlHandler = true;
}
...
if (enableHttpsUrlHandler) {
// L1040
protocols.add("https");
}
// -> --enable-url-protocols=http,https
```
`quarkus.native.enable-https-url-handler` defaults to `false`
(`NativeConfig#enableHttpsUrlHandler`), and GraalVM still enables only the
`file` and `resource` URL protocols by default. `--enable-url-protocols` is
deprecated in favour of reachability metadata, but it is what Quarkus still
emits and it still works.
So producing `ExtensionSslNativeSupportBuildItem` is what puts `https` into
`--enable-url-protocols`. If no extension in an application produces it, `new
URL("https://...";).openConnection()` fails at runtime in native mode unless the
user sets `quarkus.ssl.native=true` or
`quarkus.native.enable-https-url-handler=true`.
Two further signals that it is not deprecated: Quarkus 3.39.2 still produces
the build item from around 30 of its own extensions (`kafka-client`,
`rest-client`, `oidc`, `mongodb-client`, `redis-client`,
`elasticsearch-rest-client-common`, ...), and the build item javadoc describes
it as current API.
### What that means for us
We produce it from 45 extensions. They are not no-ops, but they are probably
not all necessary either. It is a per-extension question of transport:
* Component reaches HTTPS endpoints through `java.net.URL` /
`HttpURLConnection` — the build item is required.
* Component uses Netty, Vert.x, OkHttp or Apache HttpClient sockets directly
— the https URL protocol handler is not needed, provided nothing else in that
dependency tree falls back to `URL.openConnection()`.
Since the failure mode only appears at runtime in native mode, any removal
would need a native test that actually exercises a TLS connection for the
extension concerned.
*This review was generated by an AI agent and may contain inaccuracies.
Please verify all suggestions before applying.*
*Claude Code on behalf of James Netherton*
--
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]
