Fix #2790: expose publisher confirms on spring-rabbitmq-sink

[oscerd]

Fixes #2790.

Publisher confirms need two things wired together, and spring-rabbitmq-sink exposed neither. This adds all three knobs, in the places they actually live.

Where each option belongs

The issue suggested a confirmType property. That one is not an endpoint option — the confirm mode is a property of the connection factory, and only confirm / confirmTimeout exist on the camel-spring-rabbitmq endpoint:

[properties] confirm:        type=enum default=auto  enum=['auto', 'enabled', 'disabled']
[properties] confirmTimeout: type=duration default=5000

Confirmed against Spring's own class, which is what the template already instantiates inline:

public void setPublisherConfirmType(CachingConnectionFactory$ConfirmType);
    ConfirmType SIMPLE;  ConfirmType CORRELATED;  ConfirmType NONE;

So the split is:

property	goes to	values
publisherConfirmType	the CachingConnectionFactory bean	NONE (default), SIMPLE, CORRELATED
confirm	the endpoint	auto (default), enabled, disabled
confirmTimeout	the endpoint	ms, default 5000, negative waits indefinitely

I used the name publisherConfirmType rather than the issue's confirmType because it is the name of the underlying setter — inventing a second name for the same thing would be one more mapping for a reader to hold.

    beans:
      - name: connectionFactory
        type: "#class:org.springframework.amqp.rabbit.connection.CachingConnectionFactory"
        properties:
          ...
          publisherConfirmType: "{{publisherConfirmType}}"

          parameters:
            ...
            confirm: "{{confirm}}"
            confirmTimeout: "{{confirmTimeout}}"

The trap this is worth documenting

Setting confirm: enabled while leaving publisherConfirmType at NONE gives you a sink that looks configured for confirms but has nothing to wait on. Both descriptions say so explicitly, because it is the natural mistake given the options are on two different objects.

Compatibility

Nothing changes for existing users. publisherConfirmType defaults to NONE, which is the current behaviour — confirms stay off unless opted into. confirm defaults to auto, matching the component default, and auto with a NONE factory means no waiting.

Verification

script/validator reports no errors, script/generator produces no doc changes, mvn clean install passes from the repository root.

Binding checked against the real component with camel run, since a string-to-enum conversion on a bean property is exactly the sort of thing that silently fails:

Routes startup (total:1 started:1 kamelets:1)
    Started rmq-probe (timer://t)
... AmqpConnectException: java.net.ConnectException: Connection refused

The route starts with publisherConfirmType: CORRELATED, confirm: enabled, confirmTimeout: 3000 — the connection factory is constructed and the enum conversion succeeds — and fails only because there is no broker on localhost. A bad enum value or a misnamed bean property would have failed during startup instead. The defaults-only case (none of the three set) also starts cleanly, which is the regression check that matters here.

No Citrus test: exercising confirms needs a live RabbitMQ, and there is no broker in the project's Citrus toolchain for this component.

---

Claude Code on behalf of Andrea Cosentino