oscerd opened a new pull request, #2964:
URL: https://github.com/apache/camel-kamelets/pull/2964
Fixes #2957
### mail-sink — the documented `ce-*` interface was dead code
`docs/modules/ROOT/partials/mail-sink-description.adoc` documents:
> **Email Headers Support** — `ce-subject`: Override email subject,
`ce-from`: Override sender address, `ce-to`: Override recipient address,
`ce-cc`: Add CC recipients
The template maps those onto `Subject` / `From` / `To` / `Cc`. But
`camel-mail` only honours those headers when the matching option is enabled,
and in Camel 4.22.0 all four default to **`false`**:
| option | default |
|---|---|
| `useHeaderSubject` | `false` |
| `useHeaderFrom` | `false` |
| `useHeaderRecipients` | `false` |
| `useHeaderReplyTo` | `false` |
`mail-sink` set none of them, so the endpoint's `{{subject}}` / `{{from}}` /
`{{to}}` always won and the documented overrides did nothing.
This PR enables the three options the documented interface needs, and adds
the header discipline that then becomes necessary:
- Bare `Subject` / `From` / `To` / `Cc` / `Bcc` / `Reply-To` headers
arriving from upstream are stripped **first**, so only the `ce-*` mappings can
set them. Without this, turning on `useHeaderRecipients` would also let a bare
`Bcc` — which is not part of the documented interface at all — take effect.
- `useHeaderReplyTo` stays off, and `Reply-To` is stripped, since neither is
documented.
This follows the same shape as `http-sink`'s existing `removeHeader:
CamelHttpUri`.
**Behaviour change:** `ce-subject` / `ce-from` / `ce-to` / `ce-cc` now
actually take effect. That is what the docs already promise, but it is a change
from what ships today.
### redis-sink — one typo, two dead blocks
1. The branch guarded on `${header[ce-channel]}` read
`${header[ce-channell]}` (line 118). Supplying `ce-channel` entered the branch
and then set an **empty** channel. `ce-channell` appears nowhere else in the
catalog.
2. The `value` and `message` `choice` blocks were followed unconditionally
by:
```yaml
- setHeader: {name: CamelRedis.Message, simple: "${body}"}
- setHeader: {name: CamelRedis.Value, simple: "${body}"}
```
so whatever those blocks set was immediately overwritten — the body always
won. Unlike mail-sink, the redis-sink docs promise nothing about a header
interface, so rather than silently flipping precedence I removed the dead
blocks and left body-wins exactly as it behaves today. If header-overrides-body
is wanted here, that is a feature decision worth its own issue.
### Verification
- `script/validator` reports no errors
- `mvn verify` passes
- Not exercised against a live SMTP or Redis server; the `useHeader*`
defaults were read from the Camel 4.22.0 component catalog rather than from a
running route
---
_Claude Code on behalf of Andrea Cosentino_
--
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]
