oscerd opened a new pull request, #2999:
URL: https://github.com/apache/camel-kamelets/pull/2999
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:
```yaml
- 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:
```diff
- 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_
--
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]
