CAMEL-23578: camel-web3j - align Exchange header constant names with Camel naming convention

[oscerd]

Summary

Renames the Exchange header string values in Web3jConstants from non-Camel
prefixed values (OPERATION, FROM_ADDRESS, TO_ADDRESS, VALUE,
SIGNED_TRANSACTION_DATA, SHA3_HASH_OF_DATA_TO_SIGN, ETH_HASHRATE,
GAS_PRICE, GAS_LIMIT, ...) to CamelWeb3j<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 (OPERATION, FROM_ADDRESS, ...) 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).

Scope decisions

• The producer-side dispatch operation identifiers (WEB3_CLIENT_VERSION,
  ETH_GAS_PRICE, ETH_SEND_TRANSACTION, ...) keep their previous string
  values because they are operation enum values placed into the OPERATION
  header, not Exchange header names themselves. Now that the OPERATION
  header name is CamelWeb3jOperation, the dispatch values are filtered as
  part of that header's value and don't need their own Camel* prefix.
• ETH_HASHRATE is dual-purpose — it is both an operation identifier
  (the CamelWeb3jOperation value that dispatches the ethHashrate RPC)
  AND the header name read by the ETH_SUBMIT_HASHRATE operation. It is
  therefore renamed alongside the other header names; routes that referenced
  the literal string "ETH_HASHRATE" (in either role) must update to
  "CamelWeb3jEthHashrate". Routes using the symbolic constant reference
  are unaffected.
• The OPERATION constant gains an @Metadata annotation so it now appears
  in the catalog as the producer dispatch header (it previously was missing
  from the catalog despite controlling dispatch).

Generated artifacts

The following generated files are refreshed by the build and included in
this PR:

• components/camel-web3j/.../web3j.json (component catalog)
• catalog/camel-catalog/.../components/web3j.json (catalog mirror)
• components/camel-web3j/.../Web3jProducerInvokeOnHeaderFactory.java
  (dispatch table — now matches on the new CamelWeb3jEthHashrate value)
• dsl/camel-endpointdsl/.../Web3jEndpointBuilderFactory.java
  (DSL header accessors renamed: fromAddress() -> web3jFromAddress(),
  ethHashrate() -> web3jEthHashrate(), etc.)

Test changes

The producer/consumer tests previously used
Web3jConstants.OPERATION.toLowerCase() as a URI parameter name, relying on
the historical coincidence that "OPERATION".toLowerCase() happened to
equal the operation URI parameter on Web3jConfiguration. With the
constant value now CamelWeb3jOperation, that coincidence no longer holds.
The tests are updated to use the literal "operation" URI parameter
(which controls the configuration field and is unrelated to the header
rename).

Backports

camel-web3j exists on camel-4.18.x and camel-4.14.x with the same
file content. Backport is straightforward; will be filed as separate
follow-up PRs.

Test plan

• mvn clean install -DskipTests from root — full reactor build clean
• mvn test in components/camel-web3j — 132 tests, 65 pass + 67
  skipped (integration tests requiring an Ethereum node, unchanged)
• git status clean after build — only web3j-related regen artifacts
  included
• Generated DSL accessors verified to follow web3j<Name>() convention
  matching the CAMEL-23576 (camel-jira) precedent
• Upgrade guide entry added under === camel-web3j documenting old →
  new mapping and ETH_HASHRATE dual-purpose note

Tracker: CAMEL-23577

Reported by Claude Code on behalf of Andrea Cosentino

[github-actions]

🌟 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]

🧪 CI tested the following changed modules:

• catalog/camel-catalog
• components/camel-web3j
• 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 :: Web3j
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[gnodet]

Looks good overall — all 38 header values correctly renamed to CamelWeb3j* PascalCase convention. Upgrade guide is thorough.

One naming nit: HEADER_OPERATION maps to CamelWeb3jHeaderOperation, which embeds the Header implementation-detail prefix into the public header name. Meanwhile the producer-side OPERATION maps to CamelWeb3jOperation. This creates two near-synonyms whose relationship is not immediately obvious. Consider renaming the value to CamelWeb3jConsumerOperation or merging with CamelWeb3jOperation if they serve the same semantic purpose. Not a blocker.

Claude Code on behalf of Guillaume Nodet

[apupier]

Should we flag as potential breaking change similarly to https://github.com/apache/camel/pull/23441/changes ?