[PR] Fix #2791: expose sslContextParameters on the opensearch Kamelets [camel-kamelets]

["oscerd (via GitHub)" <gi...@apache.org>]

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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Fix #2791: expose sslContextParameters on the opensearch Kamelets [camel-kamelets]

["oscerd (via GitHub)" <gi...@apache.org>]

oscerd merged PR #3000:
URL: https://github.com/apache/camel-kamelets/pull/3000


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org