Skip to content

CAMEL-23579: camel-pdf - align Exchange header constant names with Camel naming convention#23437

Merged
oscerd merged 1 commit into
apache:mainfrom
oscerd:fix/CAMEL-23579
May 22, 2026
Merged

CAMEL-23579: camel-pdf - align Exchange header constant names with Camel naming convention#23437
oscerd merged 1 commit into
apache:mainfrom
oscerd:fix/CAMEL-23579

Conversation

@oscerd
Copy link
Copy Markdown
Contributor

@oscerd oscerd commented May 21, 2026

Summary

Renames the Exchange header string values in PdfHeaderConstants from non-Camel
prefixed values (protection-policy, pdf-document, decryption-material,
files-to-merge) to CamelPdf<Name>, following the convention used across
the rest of the Camel component catalog and matching the pattern established
in CAMEL-23526 (camel-cxf), CAMEL-23522 (camel-mail), CAMEL-23461
(camel-aws-bedrock), CAMEL-23532 (camel-vertx-websocket /
camel-atmosphere-websocket / camel-iggy), and CAMEL-23576 (camel-jira).

The Java field names (PROTECTION_POLICY_HEADER_NAME, PDF_DOCUMENT_HEADER_NAME,
DECRYPTION_MATERIAL_HEADER_NAME, FILES_TO_MERGE_HEADER_NAME) are unchanged
so routes referencing the constants symbolically continue to work; routes
using the literal string values must be updated (documented in the 4.21
upgrade guide).

Why it matters

The previous header names (protection-policy, pdf-document,
decryption-material, files-to-merge) sit outside the Camel* namespace
that DefaultHeaderFilterStrategy filters at transport boundaries. The
pdf-document and decryption-material headers carry security-sensitive
PDFBox objects (PDDocument, DecryptionMaterial); protection-policy
carries the encryption settings used when writing the PDF. Untrusted producers
upstream of a PDF processing route could previously inject these headers
without them being filtered, allowing an attacker who controls a transport
hop (HTTP, JMS, etc.) to swap in their own PDDocument or bypass encryption
expectations. Aligning the values with the Camel* namespace lets the
default header filter do its job.

Generated artifacts

  • components/camel-pdf/.../pdf.json (component catalog)
  • catalog/camel-catalog/.../components/pdf.json (catalog mirror)
  • dsl/camel-endpointdsl/.../PdfEndpointBuilderFactory.java — DSL header
    accessors renamed (protectionPolicy()pdfProtectionPolicy(),
    decryptionMaterial()pdfDecryptionMaterial(),
    filesToMerge()pdfFilesToMerge(); pdfDocument() keeps its name
    but returns the new value CamelPdfDocument)

Backports

camel-pdf exists on camel-4.18.x (identical source) and camel-4.14.x
(same constant values, slightly older Javadoc style). Backports are
straightforward and will be filed as follow-up PRs.

Test plan

  • mvn test in components/camel-pdf — 10 tests pass
  • Build the module, catalog module and camel-endpointdsl from a clean
    state, verify only camel-pdf regen artifacts appear in git status
  • Tests use symbolic constant references, so no test changes needed
  • Upgrade guide entry added under === camel-pdf

Tracker: CAMEL-23577

Reported by Claude Code on behalf of Andrea Cosentino

@oscerd oscerd requested review from davsclaus and gnodet May 21, 2026 16:18
@github-actions
Copy link
Copy Markdown
Contributor

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

  • First-time contributors require MANUAL approval for the GitHub Actions to run
  • You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
  • You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
  • Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 21, 2026

🧪 CI tested the following changed modules:

  • catalog/camel-catalog
  • components/camel-pdf
  • docs
  • dsl/camel-endpointdsl
All tested modules (10 modules)
  • Camel :: Catalog :: Camel Catalog
  • Camel :: Endpoint DSL
  • Camel :: JBang :: MCP
  • Camel :: JBang :: Plugin :: Route Parser
  • Camel :: JBang :: Plugin :: TUI
  • Camel :: JBang :: Plugin :: Validate
  • Camel :: Launcher :: Container
  • Camel :: PDF
  • Camel :: YAML DSL :: Validator
  • Camel :: YAML DSL :: Validator Maven Plugin

⚙️ View full build and test results

Copy link
Copy Markdown
Contributor

@gnodet gnodet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good — all 4 header values correctly renamed to CamelPdf* PascalCase convention. Upgrade guide entry is thorough with old-to-new mapping and Endpoint DSL accessor renames.

Minor: the PR title says CAMEL-23579 but the body says "Tracker: CAMEL-23577" — might want to align those.

Claude Code on behalf of Guillaume Nodet

…mel naming convention

Renames the Exchange header string values in PdfHeaderConstants from non-Camel
prefixed values (protection-policy, pdf-document, decryption-material,
files-to-merge) to CamelPdf<Name>, following the convention used across the
rest of the Camel component catalog and matching the pattern established in
CAMEL-23526 (camel-cxf), CAMEL-23522 (camel-mail), CAMEL-23461
(camel-aws-bedrock), CAMEL-23532 (camel-vertx-websocket /
camel-atmosphere-websocket / camel-iggy), and CAMEL-23576 (camel-jira).

The Java field names (PROTECTION_POLICY_HEADER_NAME, PDF_DOCUMENT_HEADER_NAME,
DECRYPTION_MATERIAL_HEADER_NAME, FILES_TO_MERGE_HEADER_NAME) are unchanged
so routes referencing the constants symbolically continue to work; routes
using the literal string values must be updated (documented in the 4.21
upgrade guide).

The generated Endpoint DSL header accessors on PdfHeaderNameBuilder have
been renamed accordingly:
- protectionPolicy() -> pdfProtectionPolicy()
- decryptionMaterial() -> pdfDecryptionMaterial()
- filesToMerge() -> pdfFilesToMerge()
- pdfDocument() unchanged in name but returns "CamelPdfDocument"

All existing tests use symbolic constant references and continue to pass
without changes.

Tracker: CAMEL-23577

Reported by Claude Code on behalf of Andrea Cosentino

Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants