oscerd commented on issue #1798: URL: https://github.com/apache/camel-kafka-connector/issues/1798#issuecomment-5729347804
Closing this out. **Part 1** — the five checked-in config classes that declared a `format: password` option as `ConfigDef.Type.STRING` — was resolved in #1809. Running the generator resynced them to `ConfigDef.Type.PASSWORD`, and there are currently 0 mismatches for `format: password` properties. **Part 2** (hardening the generator so the drift can't recur) — after digging into it, a generator change isn't warranted: - **`x-descriptors: urn:camel:group:credentials` should *not* drive `ConfigDef.Type.PASSWORD`.** That descriptor is a credentials-*group* UI marker that the kamelets attach to identity fields as well as secrets. For example, `aws-redshift-sink` declares `username` with `x-descriptors: [urn:camel:group:credentials]` and **no** `format: password`. Keying PASSWORD off that descriptor flips ~80 generated config classes and masks usernames and other non-secret identity options — a regression. So `format: password` is the correct (and sufficient) mask signal, which the generator already uses. - **Primitive-typed secrets don't occur.** Every property declaring `format: password` in the current catalog is `type: string`, so `PRIMITIVE_TYPES_TO_KAFKA_CONFIG_DEF_MAP.getOrDefault(type, CONFIG_DEF_TYPE_PASSWORD)` already returns `PASSWORD` for every real case; the primitive fall-through is only theoretical. Net: the generator's current behaviour (mask on `format: password`) is correct, and part 1 already shipped, so there's nothing left to change here. -- 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]
