oscerd opened a new pull request, #3000:
URL: https://github.com/apache/camel-kamelets/pull/3000
Fixes #2791.
The issue offers two approaches. The first — mapping the component's SSL
parameters onto Kamelet properties — turns out not to be available, so this
implements the second.
## Why not scalar properties
`camel-opensearch` has no scalar TLS options to map. Its entire TLS surface
is:
```
[componentProperties] enableSSL: boolean
[componentProperties] sslContextParameters:
org.apache.camel.support.jsse.SSLContextParameters
[componentProperties] useGlobalSslContextParameters: boolean
[properties] enableSSL: boolean
[properties] certificatePath: String
[properties] sslContextParameters:
org.apache.camel.support.jsse.SSLContextParameters
[properties] hostnameVerifier:
javax.net.ssl.HostnameVerifier
```
There is nothing for cipher suites, TLS version, keystores or hostname
verification to bind to individually — all of it lives inside
`SSLContextParameters`. So the Kamelet has to hand over that object one way or
another.
## Why not build the bean in the template
The catalog's usual idiom would be to construct it in `template.beans` from
scalar properties, the way `aws-redshift-sink` builds its `BasicDataSource`.
That does not work here, for a reason worth recording:
- Kamelet beans are created **unconditionally** — there is no way to build
one only when the operator supplies keystore properties.
- `sslContextParameters` **takes precedence over `certificatePath`** (the
component says so explicitly).
Together those mean an always-present `SSLContextParameters` bean would
silently disable the existing `certificate` property for every current user,
whether or not they wanted advanced TLS. That is a regression I am not willing
to ship for an enhancement.
## What this does
One optional property per Kamelet, pointing at a bean the operator registers:
```yaml
sslContextParameters:
title: SSL Context Parameters
description: >-
Reference to a registry bean of type
org.apache.camel.support.jsse.SSLContextParameters,
written as "#bean:myBeanName". ...
type: string
```
```yaml
certificatePath: "base64:{{?certificate}}"
sslContextParameters: "{{?sslContextParameters}}"
```
Passed with `{{?...}}`, so when unset the parameter is omitted from the
endpoint URI entirely and nothing changes for existing users. When set, it
unlocks everything the issue asked for at once — mTLS client keystore, custom
trust store, TLS protocol version, cipher suites — because those are all fields
of `SSLContextParameters`.
## Verification
`script/validator` reports no errors; `mvn clean install` passes **with
tests** from the repository root.
Behaviour checked against the real component, with both paths in a single
run:
```
Routes startup (total:2 started:2 kamelets:2)
```
- route 1, `sslContextParameters: "#bean:mySsl"` — the endpoint resolves the
registry bean and connects over **https**, failing only with connection refused
since there is no cluster on localhost. An unresolvable bean or a rejected
option would have failed at startup instead.
- route 2, property unset — starts unaffected, confirming the opt-out path
is untouched.
## One thing for reviewers to weigh
This is the catalog's **first** user-supplied bean reference. Every existing
`#bean:{{...}}` in the catalog (`aws-redshift-sink`, `databricks-*`,
`avro-*-action`, the kafka batch sources) points at a **template-local** bean
the Kamelet itself declares. Here the bean comes from the operator's registry
instead.
I think that is the right trade for this case, given the two constraints
above, and it is how Camel models the option. But it is a genuine pattern
decision rather than a mechanical change, so if you would rather the catalog
not grow that surface I am happy to close this and instead document in the
Kamelet description that advanced TLS requires a custom integration.
`hostnameVerifier` is the other bean-typed option on this component. I left
it out deliberately — it is separable, and one new pattern per PR is enough to
judge.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_013cgbAH6uDsSJDhMdunDzTS
--
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]
