Fix #2249: stop the pulsar serviceUrl being URI-decoded twice

[oscerd]

Fixes #2249.

Two years on, this still reproduces — I hit it on Camel 4.21 with the exact snippet from the issue:

Invalid service-url pulsar ssl://localhost:1234 provided
  Illegal character in scheme name at index 6: pulsar ssl://localhost:1234
Caused by: java.net.URISyntaxException

Cause

serviceUrl was interpolated straight into the endpoint URI:

- to:
    uri: pulsar:{{topicType}}/{{tenant}}/{{namespaceName}}/{{topic}}
    parameters:
      serviceUrl: "{{serviceUrl}}"

so the value is query-parameter decoded twice — once for the kamelet: URI the caller writes, and again when the template assembles pulsar:...?serviceUrl=. A + survives the first pass and becomes a space on the second, which is why the very common pulsar+ssl:// scheme reaches the Pulsar client as pulsar ssl://.

That is also exactly why the reporter's double-RAW() workaround works: one RAW per decode.

Fix

Wrap the placeholder in RAW() inside the template, protecting the value on the inner hop where the second decode happened:

-      serviceUrl: "{{serviceUrl}}"
+      serviceUrl: "RAW({{serviceUrl}})"

pulsar-source carried the identical interpolation, so it is fixed alongside — the report only mentions the sink, but the source would fail the same way against a TLS broker.

Verification

Ran both spellings against the real component. Neither produces the URISyntaxException any more, and the Pulsar client confirms the scheme survived:

what the user passes	result
serviceUrl: pulsar+ssl://localhost:1234	No available hosts found for service url: pulsar+ssl://localhost:1234
serviceUrl: RAW(pulsar+ssl://localhost:1234)	same

Reaching "no available hosts" is the success condition here — it means the URL parsed and the client tried to connect, with the + intact. There is no broker on localhost, which is all that fails.

Both spellings mattering is the point: the plain value now behaves as users expect, and the double-RAW workaround from the issue keeps working rather than breaking for anyone who already adopted it.

script/validator reports no errors and mvn clean install passes with tests from the repository root.

Note for reviewers

I scoped this to serviceUrl, the property in the report and the only one whose documented values routinely contain a +. The same double-decode applies in principle to any pulsar property carrying URI-significant characters — authenticationParams is the plausible next one — but I would rather not blanket-wrap properties on speculation, since RAW() also changes how a trailing ) is treated. Happy to extend it if you would prefer the whole parameter block hardened.

---

Claude Code on behalf of Andrea Cosentino