davsclaus commented on PR #26755: URL: https://github.com/apache/camel/pull/26755#issuecomment-5791124017
Follow-up on my review — I went and found the change that fixed this on `main`, and it turns out the 404 you were chasing was fixed a month ago, in a different component. **`3c8343102df9` — "Fix contract-first REST DSL 404 when OpenAPI base path is root"** (Thomas Raddatz, 2026-08-27, #25752). It is in `camel-platform-http-vertx`, not `camel-rest-openapi`, which is why nothing relevant showed up when diffing this component between `camel-4.22.0` and `main`. The real mechanism: `determineBasePath()` returning `"/"` is fine in itself — the damage was at the point of use, where `VertxPlatformHttpConsumer` concatenated `r.getBasePath() + r.getBaseUrl()` into `"/" + "/hello"` = `"//hello"`. Vert.x normalizes the doubled slash away when matching incoming requests, so the route was registered at a path no request could ever reach. The fix adds `buildNormalizedEndpoint()`, which strips a trailing slash from the base path before concatenation. Worth noting that this is exactly the shape I suggested in my review: normalize `"/"` where the path is assembled, rather than change what `determineBasePath` returns for one particular input. Good corroboration that the base-path contract is not the thing to change. It was also already backported: `a5b595083049` landed on `camel-4.22.x` the same day (#25792) and is an ancestor of the `camel-4.22.1` tag, so **the fix is released in 4.22.1**. If you can reproduce the original 404 on 4.22.0, upgrading to 4.22.1 should clear it — that would be a useful confirmation either way. Given that, I would suggest closing this PR. But there *is* still a real, unclaimed piece of CAMEL-24825 if you want it, and it is nicely scoped: > A contract with **no** `servers` entry at all fails to start with `URI is not absolute`. I have narrowed the ticket to just that item and recorded the above there. That message is not Camel's — the string appears nowhere in our source, so it is the JDK's `java.net.URI` message surfacing from a dependency (swagger-parser is the likely origin). The work is to catch it at the specification-load boundary and replace it with something that actually names the missing `servers` entry, or to default the base path there. That is a much better bug than this one: the current failure mode tells a user nothing about what is wrong with their contract. One thing from your branch is worth keeping regardless of which direction you go: the `openapi != null` guard you added in `RestOpenApiEndpoint.determineBasePath`. The old code would NPE inside `getBasePathFromOpenApi`, so that is a genuine fix on its own. Thanks for the careful investigation on this — the analysis was sound, it just landed on a bug that had already been closed from another angle. _Claude Code on behalf of @davsclaus_ -- 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]
