Repository navigation
camel-crypto: certificateName is a Certificate reference, not a PrivateKey - #29539
Conversation
…teKey The setter javadoc of certificateName, which the catalog and the endpoint DSL copy, said "Sets the reference name for a PrivateKey that can be found in the registry", the same text as privateKeyName. The setter looks the name up as a java.security.cert.Certificate, so say so.
davsclaus
left a comment
There was a problem hiding this comment.
Thanks, the fix is right. setCertificateName looks up a Certificate (DigitalSignatureConfiguration.java:291), and the javadoc is where the generator takes the description from. The component and camel-catalog crypto.json entries and DigitalSignatureEndpointBuilderFactory are updated consistently.
One generated file is missing. certificateName is also a component option, so dsl/camel-componentdsl/.../CryptoComponentBuilderFactory.java still says "Sets the reference name for a PrivateKey that can be found in the registry." (around line 93). The regen will change it to "Certificate" and CI will fail on uncommitted changes. Please regenerate it and commit it as well.
Heads-up: #29550 changes the keystore line right below this one in both crypto.json files, so whichever merges second will need a rebase and regen.
Reviewed with Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
certificateName is a component option as well as an endpoint option, so CryptoComponentBuilderFactory carries the same javadoc and still said PrivateKey. privateKeyName, two options below, keeps its wording.
|
Thanks — added in e561dd8. I checked the other generated crypto files: On the overlap with #29550: understood. That PR now touches the |
✅ Generated files are up to dateAn earlier CI run reported uncommitted generated changes; the latest run no longer does. |
davsclaus
left a comment
There was a problem hiding this comment.
Thanks, CryptoComponentBuilderFactory now says "Certificate" for certificateName and matches the generator output exactly (compared with the regen patch from the first CI run). As noted before, this PR and #29550 both change crypto.json, so whichever merges second needs a rebase and regen. Please also mention the component DSL change in the PR description.
Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 10 of 722 tested, 24 compile-only — current: 10 all testedMaveniverse Scalpel detected 10 affected modules (current approach: 10). Skip-tests mode would test 10 modules (4 direct + 9 downstream), skip tests for 24 (generated code, meta-modules) Modules Scalpel would test (10)
Modules with tests skipped (24)
All tested modules (37 modules, 6m 57s total)Total reactor time: 6m 57s
Top 20 slowest modules:
|
DigitalSignatureConfigurationhas three registry-reference options and documents two of them identically:publicKeyNamePublicKeyprivateKeyNamePrivateKeycertificateNameCertificateThe javadoc is the text the generator reads (no
descriptionon the@UriParam), so it is corrected there, and the copies incrypto.json(component andcamel-catalog, kept byte-identical) andDigitalSignatureEndpointBuilderFactoryare updated to match.privateKeyName's description, which is correct, is untouched.Doc-only change.